CN114640452A

CN114640452A - Method, system and consensus node for realizing distributed key generation on block chain

Info

Publication number: CN114640452A
Application number: CN202210325947.4A
Authority: CN
Inventors: 李康
Original assignee: Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2022-03-29
Filing date: 2022-03-29
Publication date: 2022-06-17
Anticipated expiration: 2042-03-29
Also published as: CN114640452B

Abstract

A method, a system and a consensus node for realizing distributed key generation on a block chain comprise: each consensus node generates n secret shares, reserves one secret share per consensus node, and encrypts and sends n-1 secret shares to other n-1 nodes respectively; each consensus node generates a public verification parameter corresponding to the secret share of the consensus node and broadcasts the public verification parameter through a contract on the chain; the contract adds the number of the node requesting broadcasting to the first node set; each consensus node verifies each received secret share and the corresponding public verification parameter, and sends the node number failed in verification to the contract through the complaint transaction; the contract determines a second node set according to the node number which fails in verification and is sent by each consensus node and the first node set; each consensus node calculates a public key share based on the verification parameters and the second node set, and calculates a corresponding private key share based on the local secret share and the second node set.

Description

Method, system and consensus node for realizing distributed key generation on block chain

Technical Field

The embodiment of the specification belongs to the technical field of block chains, and particularly relates to a method, a system and a consensus node for realizing distributed key generation on a block chain.

Background

The Blockchain (Blockchain) is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism, an encryption algorithm and the like. In the block chain system, data blocks are combined into a chain data structure in a sequential connection mode according to a time sequence, and a distributed account book which is not falsifiable and counterfeitable is ensured in a cryptographic mode. Because the blockchain has the characteristics of decentralization, information non-tampering, autonomy and the like, the blockchain is also paid more and more attention and is applied by people.

Disclosure of Invention

An object of the present specification is to provide a method, a system, and a consensus node for implementing distributed key generation on a blockchain, including:

a method of initiating a distributed key generation process on a blockchain, comprising:

a first common node on the block chain monitors a system instruction or a predetermined event on the block chain, and initiates a transaction for starting a distributed key generation process to a distributed key generation contract after monitoring;

after receiving the transaction for starting the distributed key generation process, the distributed key generation contract generates a corresponding starting event and places the starting event in a receipt of a block where the transaction for starting the distributed key generation process is located;

and each consensus node on the block chain monitors the starting event in the receipt corresponding to the distributed key generation contract in the generated block, and starts the distributed key generation process after monitoring.

A blockchain system comprising a plurality of consensus nodes, wherein:

a first common node on the block chain monitors a system instruction or a predetermined event on the block chain, and initiates a transaction for starting a distributed key generation process to a distributed key generation contract after monitoring; after receiving the transaction for starting the distributed key generation process, the distributed key generation contract generates a corresponding starting event and places the starting event in a receipt of a block where the transaction for starting the distributed key generation process is located;

In the above scheme provided in this specification, each node may start the distributed key generation process approximately synchronously, thereby completing the distributed key generation process of the same round in cooperation.

Drawings

FIG. 1 is a diagram illustrating a conventional phase of a practical Byzantine fault tolerance algorithm in one embodiment;

FIG. 2 is a diagram illustrating a view switching phase of an embodiment of a practical Byzantine fault-tolerant algorithm;

FIG. 3 is a diagram illustrating a conventional stage of a practical Byzantine fault tolerance algorithm in an embodiment where none of the consensus nodes are down;

FIG. 4 is a flow chart of random number seed generation on a blockchain in one embodiment of the present disclosure;

FIG. 5 is a block head structure in an embodiment of the present disclosure;

FIG. 6 is a flow chart of random number seed generation on a blockchain in one embodiment of the present disclosure;

FIG. 7 is a block chain method for distributed key generation in an embodiment of the present disclosure;

fig. 8 is a method for implementing distributed key generation on a blockchain in an embodiment of the present disclosure.

Detailed Description

In order to make those skilled in the art better understand the technical solutions in the present specification, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only a part of the embodiments of the present specification, and not all of the embodiments. All other embodiments obtained by a person skilled in the art based on the embodiments in the present specification without any inventive step should fall within the scope of protection of the present specification.

The blockchain 1.0 era generally refers to the blockchain application development stage between 2009 and 2014, which is mainly aimed at solving the decentralization problem of currency and payment means. Since 2014, developers have increasingly focused on addressing the deficiencies of the foregoing in technology and extensibility. In 2013, vitarik business introduced intelligent contracts into blockchains, and opened the application of blockchains outside the currency field, thereby opening the 2.0 era of blockchains.

In the block chain system, different participants can establish a distributed block chain network through deployed nodes (nodes). A decentralized (or multi-centric) distributed book constructed using a chained blockchain structure is maintained at each node (or at most nodes, such as a consensus node) in the distributed blockchain network. Such a blockchain system needs to address the issue of consistency and correctness of the respective ledger data across multiple nodes that are decentralized (or multicenter). Each node (or multiple nodes) runs a blockchain program, and under the design of certain fault tolerance requirements, all loyalty nodes are guaranteed to have the same transaction through a consensus mechanism, so that the execution results of all loyalty nodes on the same transaction are guaranteed to be consistent, and the transaction and the execution results are packaged to generate a block.

An intelligent contract is a computer contract that executes automatically based on specified trigger rules and may also be considered a digital version of a traditional contract. The concept of smart contracts was first proposed by cross-domain law workers, cryptology researchers, Nick Szabo (Nick Szabo) in 1994. This technology has not been used in the actual industry for the first time due to the lack of programmable digital systems and related technologies, until the advent of blockchain technology to provide a reliable execution environment for it. Because the block chain technology adopts the block chain type account book, the generated data can not be falsified or deleted, and the account book data is continuously added to the whole account book, thereby ensuring the traceability of the historical data; meanwhile, the decentralized operation mechanism avoids the influence of centralized factors. The intelligent contract based on the block chain technology not only can exert the advantages of the intelligent contract in the aspects of cost and efficiency, but also can avoid the interference of malicious behaviors on the normal execution of the contract. The intelligent contracts are written into the block chain in a digital form, and the characteristics of the block chain technology ensure that the whole process of storage, reading and execution is transparent, traceable and not falsifiable.

Block chain development and application are diversified. Some business logic is compiled into intelligent contracts and executed on a blockchain platform. In particular, these intelligent contracts containing business logic may be run on each node (or on most nodes, such as consensus nodes) in the blockchain network. The problem with executing intelligent contracts in blockchain environments is also referred to as "world computers" because there are many nodes in a distributed blockchain network that each independently execute intelligent contracts, as opposed to a single point of failure from a centralized business logic execution environment, which results in the unavailability of the entire centralized system. As mentioned above, the intelligent contracts executing the same logic on these different nodes need to obtain the same execution result, so as to ensure that the majority of the accounts stored in these nodes are consistent.

In some business logic, it may be necessary to generate a result based on a random number, such as business logic for implementing a lottery, business logic for implementing a shaking number, or business logic for implementing a red packet or a blind box for a range of random amounts, which generally requires a program for generating a random number to be included in an intelligent contract. For another example, in some system contracts, voting on a master node or voting on a small committee may need to be performed, and this voting logic may be implemented in a random manner or by using a random number. As mentioned above, a significant feature of the distributed blockchain network is that accounts in most nodes are consistent in order to ensure that the distributed blockchain network is entirely available, which also requires that random numbers generated by intelligent contracts in most nodes are consistent.

As mentioned above, a blockchain program is run on each node (or multiple nodes), and under the design of certain fault tolerance requirement, all loyalty nodes are guaranteed to have the same transaction through a consensus mechanism, so that the execution results of all loyalty nodes on the same transaction are guaranteed to be consistent, and the transaction and the execution results are packaged to generate a block. The current mainstream consensus mechanisms include: proof of Work (POW), Proof of stock (POS), Proof of commission rights (DPOS), Practical Byzantine Fault Tolerance (PBFT) algorithm, badger Byzantine Fault Tolerance (honeybadger bft) algorithm, and the like.

Taking PBFT as an example, the algorithm is proposed in 1999 by Miguel Castro (Castoterol) and Barbara Liskov (Rickov), solves the problem of low efficiency of the original Byzantine fault-tolerant algorithm, reduces the complexity of the algorithm from exponential level to polynomial level, and enables the Byzantine fault-tolerant algorithm to be feasible in practical system application. This paper was published at 1999 international conference on operating system design and implementation (OSDI 99). In the PBFT algorithm, all copies (replica) are run in a rotation process called View (View). In a certain view, one copy serves as a primary node (primary) and the other copies serve as backup nodes (backups). Views are consecutively numbered integers. The master node can be calculated by the formula p ═ v mod | R |, where v is the view number, p is the copy number, and | R | is the number of copy sets. The assumption in this algorithm is that when there are at most f copies (i.e., nodes) that fail, if there are a total of at least 3f +1 copies, it is guaranteed that security and activity will be provided in the asynchronous system. The set of a certain number of replicas, which is required in order to be able to ensure the data consistency requirements and fault tolerance requirements of all replicas, is typically the set of most nodes in a distributed system, constituting the majority (Quorum). For example, in the case where the total node number n is 3f +1 (the case where n is 3f +2 or n is 3f generally does not improve the fault tolerance effect), the Quorum is 2f + 1. Thus, for a distributed system comprising four nodes, any three nodes may constitute a Quorum.

PBFT includes two processes, Normal Case Phase and View Change Phase, and FIG. 1 is a flow chart of the Normal Case Phase (conventional Phase) process. The Normal Case Phase mainly includes three phases of PRE-PREPARE, and COMMIT, where node number 3 may represent, for example, a down node (represented by x in fig. 1). When a Primary node fails (denoted by x in fig. 2, for example, a Primary node Primary before view change, that is, a Primary node Primary 0 (copy 0) fails), a view change (view change) process needs to be started, so that adjustment is performed when a system has a failure, and a new Primary node is changed (for example, a Primary node Primary is a Primary node Primary after view change). FIG. 2 is a View of View Change Phase. The client may set a timeout mechanism if the master node drops or goes bad without broadcasting the client's request, etc. If timed out, the client may broadcast a request message to all replica nodes. After detecting that the master node is malicious or offline, the replica node may also initiate a View Change protocol stage to Change the master node (often referred to as "master Change"). In addition, the PRE-PREPARE, PREPARE and COMMIT three-stage consensus process may fail due to the proposal of the primary node initiating an error, or the PREPARE and COMMIT stages may not be consistent with the Quorum number (e.g., 2f +1 of 3f +1 nodes, also referred to as a Quorum number), and the consensus may not be completed. It is also possible in these cases to initiate a View Change protocol phase to replace the master node.

Under Normal conditions, that is, no fault occurs in the common node, and the common message can reach the other party within a certain time, that is, no change of owner occurs, the Normal Case Phase process in the PBFT may be as shown in fig. 3, which still takes 4 common nodes as an example.

In the Normal Case Phase process of round r-1, after the node 0 is used as a master node to collect a certain number of transactions to be identified (or a read/write set, etc., and the transactions are described later as an example), a preparation process is initiated (i.e., the PRE-PREPARE stage is also referred to as a PP stage), and then the

nodes

1,2, and 3 enter the preparation process (i.e., the PREPARE stage is also referred to as a P stage), and then the

nodes

0, 1,2, and 3 enter the COMMIT process (i.e., the COMMIT stage is also referred to as a C stage). The PP, P, C phases are also commonly referred to collectively as the three phases of the PBFT. Thus, the three-stage process of the r-1 th round of PBFT is completed under normal conditions, the consensus of the transaction data corresponding to the m-1 th block is completed, and information such as the block number of the block is generated. Thus, the consensus nodes can execute the transactions in sequence according to the sequence and content of the consensus transaction data based on the consensus transaction data, and further generate a world state and a receipt. Specifically, each node can construct a Merkle Tree (including Tree structures such as MPT trees, where MPTs are collectively referred to as Merkle Patricia trees, and are Tree structures combining Merkle trees and Patricia trees) based on locally-agreed transaction data, and generate a hash (also referred to as transaction root hash) of the root of the Merkle Tree, and similarly, can construct a Merkle Tree based on world state data and generate a hash (also referred to as state root hash) of the root of the Merkle Tree based on world state data, and can construct a Merkle Tree based on receipt data and generate a hash (also referred to as receipt root hash) of the root of the Merkle Tree. After each node locally generates the three root hashes, the m-1 block can be locally generated. The block header of the (m-1) th block may include information such as the aforementioned block number, transaction root hash, status root hash, receipt root hash, and the like, and the block may include a transaction data set, a world state set, and a receipt set. Thus, the m-1 th block is generated.

During the generation of the mth block, the three-stage process in the PBFT will be repeated. As shown in fig. 3, for the mth block, after collecting a certain number of transactions to be identified, node 0 serves as a master node, and initiates a PP process, and then

nodes

1,2, and 3 enter a P process, and then

nodes

0, 1,2, and 3 enter a C process. Therefore, the three-stage process of the r round of PBFT is completed under normal conditions, the consensus of the transaction data corresponding to the m block is completed, and information such as the block number of the block is generated. The nodes may each execute the transactions in sequence based on the consensus transaction data, in order of the content of the consensus transaction data, to generate a world state and a receipt. After each node locally generates the three root hashes as described above, the mth block may be locally generated. The block header of the mth block may include information such as the aforementioned block number, transaction root hash, status root hash, receipt root hash, and the like, and the block may include a transaction data set, a world status set, and a receipt set. Thus, the mth block is generated. Similarly, the (m +1) th block is generated, and this process includes a three-stage process of the (r +1) th round of PBFT as shown in FIG. 3.

It can be seen that in the Case of conventional block generation, each consensus node includes a Normal Case Phase process of PBFT once in the generation process of each block. This consensus process is repeated for each consensus node as the blocks are generated, and the r-1, r, and r +1 rounds of consensus process are shown in fig. 3 as examples only. Some of the consensus nodes play the role of a main node in the PBFT, and some of the consensus nodes play the role of a backup node in the PBFT.

In a consensus process, i.e., a three-stage process of a PBFT, may include:

a 110: (PRE-PREPARE PRE-preparation phase) after collecting a certain number of transactions to be identified, the master node 0 sorts and packages the transactions to be identified into a message m (also called an original transaction list), and sends a PRE-prefix request to the

backup nodes

1,2 and 3, wherein the PRE-prefix request comprises the original transaction list;

a 120: after receiving the pre-PREPARE request (PREPARE preparation stage), the

nodes

1,2, and 3 broadcast the hash value of the received message m through the PREPARE message if the original transaction list is checked to be legal (the broadcast content generally does not include the message m itself, because the message m includes several original transaction requests, the volume is generally large). Specifically, node 1 diffuses the preamble message to

nodes

0, 2, and 3, node 2 diffuses the preamble message to

nodes

0, 1, and 3, and node 3 diffuses the preamble message to

nodes

0, 1, and 2. Accordingly, each node also receives the preamble message broadcast by the other nodes. Each node adds both the prepare message sent by itself (which contains the hash value of message m, representing its approval) and the received prepare message (which contains the hash value of message m, representing the approvals of the other nodes) to the local Log (Log). A prepended state is reached if a node collects at least a Quorum number of legitimate pp messages/p messages from different nodes (including its own pre-prepare, prepare messages, and received prepare messages).

a 130: (COMMIT COMMIT phase) each of the nodes participating in consensus sends a COMMIT message to other nodes of consensus after entering a prepared state, adds the COMMIT message sent by itself to the local Log (representing its approval), and each node also receives the COMMIT message broadcast by other nodes. If a certain node collects legal commit messages of at least the number of the queries from different nodes, the messages are added into the local Log (the total number of the queries added into the local Log by the node is added), and the node is converted into a committed state.

a 140: and the node which is converted into the committed state outputs the message m as the consensus result of the current round.

Which transactions are contained in the message m, and the sequence of the contained transactions, is generally determined by the master node in a 110. Determining which transactions are involved, the sequence of the involved transactions, both of which are important elements of the consensus mechanism. Many transaction requests may be received in the blockchain network, and the master node in a110 packages which transactions, determines which transactions are processed by the blockchain network, and the execution result of the transactions is linked up. Even if a group of transactions are the same, the different execution sequence of the front and the back can lead to different final results, and the final results influence whether the accounts on the nodes are consistent.

The present specification provides a method for generating random number seeds on a blockchain, which can be implemented in combination with the above-mentioned three-stage PBFT process. As shown in fig. 4, includes:

s110: in the commit stage of PBFT, each consensus node signs an original message containing a unique value of an original transaction list in the consensus by adopting a private key share of the consensus node based on a threshold signature algorithm to generate a signature share, and the signature share is added into a broadcast commit message.

The threshold signature is an important branch of the common digital signature and is a combination of the threshold secret sharing technology and the digital signature. The traditional signature scheme can be realized by adopting an RSA algorithm. The RSA algorithm is an asymmetric encryption algorithm, proposed together in 1977 by ronard listeriost (Ron Rivest), addi samor (Adi Shamir) and lunard Adleman (Leonard Adleman). The RSA algorithm can complete decryption without directly transmitting the key, so that the information security can be ensured, and meanwhile, the risk of information cracking caused by directly transmitting the key is avoided. The RSA includes a private key and a public key, which are paired. After one piece of information is encrypted by the public key, the information can only be decrypted by the corresponding private key; similarly, a message is encrypted by a private key and then decrypted only by the corresponding public key. This is due to the fact that there is a correlation between the private and public keys in pairs in mathematical theory, for example, one underlying principle is that it is relatively simple to find two large prime numbers, and factoring the product of them is extremely difficult, so that the product can be disclosed as an encryption key, thereby ensuring security. The private key is typically kept strictly secret and cannot be revealed, while the public key is public (and can be held by multiple people). Because the private key is strictly kept secret by the holder, the signature of the holder of the private key cannot be forged by other people on the premise that the other people cannot obtain the private key.

The RSA signature mechanism can ensure the integrity of the message in the transmission process. For example, node a needs to transmit a message to node B, and the middle may pass through several node relays. A may employ the RSA signature mechanism to transmit the message along with the signature to B via a number of intermediate nodes, and the verification of the signature by B may be confident that the received message was sent by a and not tampered with during transmission. One process of RSA signature is as follows:

b 1: a generates a pair of keys (public key and private key), the private key is not public, and the private key is reserved by itself. The public key is public and can be obtained by anyone.

b 2: a signs the hash value of the original message by using the private key of the A, and transmits the original message and the signing result to B. As previously mentioned, this transfer process may be forwarded through several intermediate nodes.

The hash algorithm, also called hash algorithm, can map the original content into a sequence of fixed length, which is the hash value. There are hash algorithms such as sha256, sha384, sha512, etc. The result of sha256 is 256 bits, which can represent 256 powers of the original content of 2. Similarly, the result for sha384 is 384bits, and the result for sha512 is 512 bits. These hash algorithms can be applied to original content with more contents and larger volume, and thus the hash value can be relatively much smaller than that of the original content. The good hash algorithm can ensure that different original contents are mapped into different hash values with a maximum probability, and the mapping is disordered, namely the relevance of the hash values obtained by the different original contents cannot be predicted; but also are anti-adversity, i.e. the original content cannot be obtained by backward pushing the hash value.

The original message may have more contents and a larger volume, and the signature calculation of the original message directly by using the private key may be time-consuming and calculation-consuming. Therefore, the original message can be calculated to a hash value by adopting a hash algorithm, so that the hash value is smaller in length and can completely represent the original message. And then, carrying out encryption calculation on the hash value by adopting a private key, wherein the obtained result is the signature.

b 3: and B, after receiving the message, adopting the public key of A to check the signature.

On one hand, the hash value of the original message can be calculated by the B through the same hash algorithm as the A, and the hash value is calculated as hash 1; and on the other hand, B performs decryption calculation on the signature result by adopting the public key of A to obtain a hash 2. If the hash1 is the same as the hash2, it can be determined that the original message received was sent by a and has not been tampered during transmission.

The threshold signature scheme includes 1 total public key and n public and private key pairs. The 1 public key in each public-private key pair is called a public key share and the 1 private key in each public-private key pair is called a private key share. Secondly, there is a recovery function corresponding to the total public key and n public-private key pairs, which can recover the signature shares signed by at least a threshold number of different private key shares into a complete signature, and the generated complete signature can be verified as correct by the 1 total public key. Any signature shares less than the threshold number cannot be recovered from generating the full signature.

In addition to the RSA-based threshold Signature mechanism, a threshold Signature mechanism based on ECDSA (Elliptic Curve Digital Signature Algorithm), a threshold Signature mechanism based on Schnorr (a knowledge proof mechanism based on discrete logarithm puzzle), a threshold Signature mechanism based on BLS (Boneh-Lynn-Shacham Signature), and the like may be used.

It should be noted that, for the threshold signatures used in the block chain, the number of private key shares may be equal to the number of common nodes, and the number of the minimum signature shares (i.e., the number of thresholds) for the recovery function to generate a complete signature may be equal to quorum in the PBFT algorithm. Of course, the number of the private keys may not be equal to the number of the consensus nodes, and the number of the minimum signature shares of the recovery function generating the complete signature may not be equal to quorum in the PBFT algorithm. The former is described below as an example.

The 1 total public key and the n public and private key pairs can be generated by a centralized dealer and distributed to n block chain common nodes, which belongs to a centralized key distribution mode. Thus, in conjunction with the consensus algorithm, the n private key shares may be one held by each blockchain consensus node. Meanwhile, each blockchain consensus node may hold the same 1 total public key. In addition, there is a decentralized key distribution mode, that is, dealer is removed, but n public and private key pairs and 1 total public key are obtained by negotiating through a key negotiation process by n common nodes, still each common node holds one of n private key shares separately, and each common node holds the same total public key.

By adopting the threshold signature algorithm, each consensus node can adopt a private key which is unique to the consensus node (for example, in a block chain network which comprises 4 nodes and adopts PBFT as the consensus algorithm, the private key shares of the

nodes

0, 1,2 and 3 adopting the threshold signature algorithm are sk respectively₀，sk₁，sk₂，sk₃Subscript number can represent the number of the node) to sign the original message containing the unique value of the original transaction list in the consensus to obtain a signature result. Here, the unique value of the original transaction list may be used as the original message for which the signature is intended.

The unique value of the original transaction list may include the original transaction list itself or a hash value of the original transaction list. Generally, the transaction contents are different for different transactions, and thus, different original transaction lists or hash values thereof are generally different. Therefore, the original message may at least include the original transaction list or the hash value thereof, so that the property of the hash function is sufficient to distinguish the random number seeds generated after the consensus process corresponding to different blocks is completed.

Considering that a number is generated for the content of this consensus in the process of consensus, if the consensus is completed, the generated number can be used as the block number of the block corresponding to this consensus, and therefore, the block number (i.e., the number) can also be used as the content in the original message. No matter whether the original transaction list contained in the (N +1) th block is the same as the original transaction list contained in the nth block, the block generation is sequential, which can be embodied as that the block number of the next block is the block number +1 of the previous block. Therefore, the block number is used as the content in the original message, even if the original transaction list contained in the (N +1) th block is the same as the original transaction list contained in the nth block, different signatures are obtained by each node based on the (original transaction list + block number) by adopting the own private key, the master node still cannot acquire the signatures of other nodes, so that the complete signature of the (N +1) th block cannot be predicted, and therefore the master node cannot predict the random number seed of the (N +1) th block by using the published random number seed of the (N) th block, and the purpose of unpredictable is achieved. Similarly to the numbering, the time stamp is also specific to one block, and the time stamp of the following block follows the previous block. Therefore, the time stamp can also be the content in the original message.

In addition to the unique value of the original transaction list, the signed object may also have other content added, such as the random number seed generated in the previous block, i.e., the random number seed generated in the previous block may also be included in the original message. After the aforementioned a140 is performed, each node may generate the mth block based on the common transaction data, as described above. Since the mth block is generated by each node independently in the local area, if the hash values of the previous block generated by each node are not broadcast to each other among the link points of the block and compared, each node may not be able to determine whether the mth block generated in the block chain network is the same or whether the mth blocks generated on at least the quorum number of common nodes are the same from the viewpoint of overall availability of the block chain system. Through the generation process of the random number seeds in the present specification, the random number seeds of the same block should be the same, and the random number seeds in different blocks should be different, so that the random number seeds can be added to the original message. Thus, if the random number seeds corresponding to the mth block generated by each node are different, according to the property of the threshold signature algorithm, a complete signature may not be obtained through a recovery function in the process of generating the random number seeds of the (m +1) th block, so that the consensus node can be helped to confirm whether the previous blocks are consistent according to the scheme of the present specification. The hash value of the previous block can be used to replace the random number seed of the previous block, and since the hash value of one block is generally unique, the common node can also be helped to confirm whether the previous block is consistent.

And signing the original message containing the special value of the original transaction list in the consensus by adopting the own private key share, wherein the special value of the original transaction list which can be included in the original message can be the original transaction list. The original transaction list is generally already broadcast in the PP phase of the PBFT, and the commit message broadcast in the C phase is smaller, which is more favorable for propagation and bandwidth saving, so the unique value of the original transaction list can be the hash value of the original transaction list.

For the case that the original message includes multiple contents, for example, a hash value of the original transaction list, a block number, and a random number seed generated in a previous block, the hash value of the original message may be calculated first, and then the hash value of the original message is signed by using a private key share, so as to obtain a signature result.

And signing the original message, wherein the generated signature result and the original message can be added into the broadcast commit message. Thus, in the commit phase, each of the nodes participating in the consensus sends a commit message to the other consensus nodes and adds the commit message sent by itself to the local Log (representing its approval), and each node also receives commit messages broadcast by the other nodes.

S120: and after collecting the commit messages of at least the threshold number, each consensus node obtains the complete signature by passing the signature shares of at least the threshold number which pass the verification through a recovery function corresponding to the private key shares generated by the threshold signature algorithm.

As described above, in the application of the threshold signature algorithm, 1 pair of the public and private keys may be generated, and the recovery functions corresponding to the n pairs of public and private keys may be generated. As mentioned above, the recovery function may recover at least a threshold number of signatures that are verified to be correct to generate a complete signature, and a threshold value of the threshold signature algorithm, i.e. the threshold number, may be set as w. Of course, a complete signature can be generated by the recovery function when there are more than w correct signatures. That is, when the number of correct signatures is greater than or equal to the threshold number w, a complete signature can be generated by the recovery function, and the generated complete signature is determined and will not change due to the number of correct signatures input (as long as the number is greater than or equal to w).

This generated complete signature can be verified for correctness by the 1 total public key. Thus, any node holding the total public key can use the total public key to verify the correctness of the complete signature. For example, after the node 1 generates the complete signature, the integrity of the complete signature may be verified by using the total public key, for example, the complete signature is subjected to a cryptographic operation by using the total public key to obtain a first hash, and the original packet is subjected to a hash operation to obtain a second hash, and if the first hash is consistent with the second hash, the integrity of the complete signature may be determined. The integrity includes that the complete signature is for the original message and the original message has not been tampered with. For another example, after the node 1 generates the complete signature, the total public key, and the original packet may be sent to a device outside the block chain, and the device may use the total public key and the original packet to verify the correctness of the complete signature, which is not described in detail in the same principle. The message text here is still the aforementioned content containing the unique value of the original transaction list in this consensus, or further includes the block number and/or the timestamp of the current block and/or the random number seed generated in the previous block.

In addition, after each commit message is collected by each consensus node, the signature shares in the received commit messages are verified by using the corresponding public key shares, and then the signature shares with at least threshold number are subjected to a recovery function corresponding to the private key shares generated by the threshold signature algorithm to obtain a complete signature. Compared with a mode of verifying the generated complete signature by adopting the total public key, the mode of verifying each signature share by adopting the public key shares and recovering the signature into the complete signature by a recovery function after the verification is passed can determine which signature is wrong, thereby determining which node is possibly a rogue node.

In the threshold signature algorithm, each consensus node has 1 public key and 1 private key share and corresponding 1 public key share in n public and private key pairs, which may be generated and distributed by dealer as described above, or obtained by negotiation of each consensus node.

Each consensus node may verify the signature shares in the received commit message with the corresponding public key shares. Specifically, for example, in a federation chain employing the PBFT consensus algorithm including 4 consensus nodes, node 0 broadcasts a self-generated signature share σ to

nodes

1,2,3 in S110_3，0Where σ is_3，0 Subscript 3 of (a) may indicate a block number, 0 may indicate that this is a 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 its own broadcast signature share σ_3，0And the signature share σ broadcast by the

nodes

1,2_3，1、σ_3，2. Of course, node 0 may also collect all the signature shares σ_3，0、σ_3，1、σ_3，2And σ_3，3This, of course, also satisfies at least the quorum number.

Further, node 0 may verify the collected σ with the corresponding public key share_3，0、σ_3，1、σ_3，2Or also includes sigma_3，3(or is σ)_3，0、σ_3，1、σ_3，3Or also includes sigma_3，2Or is σ_3，1、σ_3，2、σ_3，3Or also includes sigma_3，0Or is σ_3，0、σ_3，2、σ_3，3Or also includes sigma_3，1) The correctness of the operation. In particular, for example, node 0 may employ a corresponding public key share to signFraction σ_3，1Calculating to obtain a hash value which is recorded as hash_3，1(ii) a Node 0 can also perform the same hash calculation on the original message to obtain hash'_3，1. If hash_3，1And hash'_3，1And the original message is proved to be sent by the node 1 and has not been tampered in the transmission process. Thus, σ_3，1The correctness of the test is verified. Similarly, node 0 may be paired with σ_3，2And the verification is performed, which is not described in detail.

Likewise, node 1 may verify the collected σ with the corresponding public key share_3，0、σ_3，1、σ_3，2Or also includes sigma_3，3(or is σ)_3，0、σ_3，1、σ_3，3Or also includes sigma_3，2Or is σ_3，1、σ_3，2、σ_3，3Or also includes σ_3，0Or is σ_3，0、σ_3，2、σ_3，3Or also includes sigma_3，1) The correctness of the operation.

Likewise, node 2 may verify the collected σ with the corresponding public key share_3，0、σ_3，1、σ_3，2Or also includes sigma_3，3(or is σ)_3，0、σ_3，1、σ_3，3Or also includes sigma_3，2Or is σ_3，1、σ_3，2、σ_3，3Or also includes sigma_3，0Or is σ_3，0、σ_3，2、σ_3，3Or also includes sigma_3，1) The correctness of the operation.

Likewise, node 3 may verify the collected σ with the corresponding public key share_3，0、σ_3，1、σ_3，2Or also includes sigma_3，3(or is σ)_3，0、σ_3，1、σ_3，3Or also includes sigma_3，2Or is σ_3，1、σ_3，2、σ_3，3Or also includes sigma_3，0Or is σ_3，0、σ_3，2、σ_3，3Or also includes sigma_3，1) The correctness of the operation.

S130: and each consensus node obtains a random number seed based on the complete signature.

Random seed (random seed) refers to the initial value used in a pseudo-random number generator to generate a pseudo-random number. For a pseudo-random number generator, the same random number sequence can be obtained starting from the same random number seed. For a stand-alone machine, the random number seed may be determined by the current state of the computer, such as the current time. For distributed systems, the same random number seed is generated at each node, so that the same random number is generated based on the same random number seed in system contracts/service contracts/blockchain platform functions, etc., and should not be generated by any node in a way that it can manipulate, predict, revoke. This needs to be determined jointly by the nodes participating in the consensus. Moreover, considering that the distributed network is often an asynchronous network or a semi-synchronous network, from the viewpoint of instantaneity, it is also necessary to generate and use random numbers when the transaction in the current block is executed.

Through the steps of S110-S120, each consensus node can normally obtain the same complete signature. Certainly, in consideration of the fault-tolerant characteristic of the distributed system, at least a quorum number of consensus nodes in a block chain network adopting the PBFT consensus algorithm can respectively obtain the same complete signature.

Thus, based on the complete signature, each consensus node can generate a random number seed by using the same random number seed generation algorithm. A simpler random number seed generation algorithm is, for example, the sha256 algorithm. Of course, the complete signature can also be used directly as a random number seed.

Through the above process, a random number seed can be generated on the block chain.

In this way, in the process of outputting the consensus result after the block chain node performs the current consensus, that is, in the process of performing a series of transactions in which the content and the sequence are determined, if an intelligent contract/system contract/block chain platform code that needs to use a random number is included, the block chain node may perform the consensus based on the random number seed of S130. For example, in an intelligent contract written in C + + language, mt19937(r) provided by C + + standard library or boost library can be used to construct a random number engine consistent across platforms, where the parameter r is a random number seed. Similarly, the random library in python and the random library in java also provide similar random number generation methods. The same random numbers may be generated under the same random number generation algorithm based on the same random number seed. Thus, for example, when each blockchain node executes the same transaction in the same block, respectively, for the same random number generation process therein, the same random number may be generated based on the same random number seed, thereby completing business logic such as a rocker, a red packet, a blind box, or completing system contract/blockchain platform functions, and obtaining consistent execution results at each node.

Besides, on the basis of the scheme, the method also comprises the following steps:

s140: each consensus node places the resulting random number seed in the block header of the current block being generated.

Fig. 4 is a block header structure of a block. In the structure shown in fig. 5, the Block header of each Block includes several fields, such as previous Block Hash previous _ Hash (Prev Hash in the figure), Nonce (this is a random number referred to by the workload certificate, different from the random number seed in the present specification, and this Nonce is not enabled in some federation chains), Timestamp, previous Block number Block Num, State Root Hash State Root, Transaction Root Hash Transaction Root, Receipt Root Hash record Root, and so on. Wherein, 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, i.e., the Hash value of the header of the previous block. The hash value of the block header may be a hash value calculated by a hash algorithm after each field contained in the block header is sequentially spliced. In this way, the next block is locked to the previous block by the block head on the block chain. Specifically, as mentioned above, the state root is a hash value of the root of the MPT tree composed of the states of all accounts in the current block, and points to the state tree state trie in the form of an MPT of the state _ root. The Transaction Root is generally a hash value of a Root node of the original Transaction list contained in the block after being organized into a tree structure, and the script Root is generally a hash value of a Root node of the tree structure after all receipts generated after the Transaction contained in the block is executed are organized.

It should be noted here that the present specification may add a field- "random number seed" in the block header, i.e., the random number seed in S130. Thus, the random number seed generated by the block can be recorded on the block chain account, and for the playback block, the transaction related to the random number in the block can be played back according to the random number seed in the block head.

In the above scheme provided by this specification, the threshold signature algorithm is combined with the PBFT consensus algorithm, so that after the original transaction list corresponding to each block is agreed by the PBFT algorithm, a complete signature can be obtained by the threshold signature algorithm, so as to obtain a random number seed.

In the above scheme provided in this specification, based on the property of the threshold signature algorithm, each consensus node may recover the same complete signature through a recovery function based on at least a threshold number of signature shares, and then generate the same random number seed, so that, when each block link point executes the same transaction in the same block, the same random number generation process may generate the same random number based on the same random number seed, thereby completing service logic such as a rocker, a red packet, and a blind box, or completing a system contract/block chain platform function, and obtaining a consistent execution result on each node.

In the above scheme provided by the present specification, a threshold signature algorithm is combined with a PBFT consensus algorithm, so that any consensus node cannot predict a complete signature before consensus is completed, and even a master node of the PBFT cannot predict a complete signature, a random number seed and a random number cannot be predicted. Particularly, when the threshold is equal to quorum, once the consensus is completed, since the content and the sequence of the transaction list are agreed by the nodes of the number of quorum, that is, the basic content of the generated new block is determined, at least the complete signatures obtained by the nodes of the number of quorum according to the recovery function are the same, the random number seeds generated by the nodes of the number of quorum are necessarily the same, and even if there are no more than f nodes which do harm and want to control or revoke the obtained random number seeds, the f nodes do not influence the consistency of the system, that is, the f nodes cannot control or revoke the generated complete signatures, random number seeds and random numbers.

The method in this specification may be implemented in the process of generating each block, and thus, a field of a random number seed may be included in the block header of each block. Even if a block of a block does not contain transactions involving random numbers, the generation of the block may still include the generation of random number seeds.

In the following blockchain network that performs a transaction in a consensus transaction list after a transaction list is known, a method for generating a random number seed on a blockchain is described in the present specification in terms of a consensus node in the blockchain network, and a consensus algorithm is employed in which a consensus result is output by mutually broadcasting a commit proposal in a last stage, and then the consensus node performs the following steps as shown in fig. 6:

s210: in the last stage of the consensus algorithm, the consensus node signs an original message containing a unique value of an original transaction list in the consensus by using a private key share of the consensus node based on a threshold signature algorithm to generate a signature share, and the signature share is added into the broadcasted consensus message.

In addition to PBFT outputting consensus results through the final stage of mutual broadcasting submission proposal, there are also consensus algorithms that output consensus results through the final stage of mutual broadcasting submission proposal, such as chinese patents ZL202111175184.1, ZL202111178795.1, ZL202111178745.3, ZL202111178754.2, ZL202111175144.7, ZL202111175151.7 and chinese patent application CN 202111178779.2.

By adopting a threshold signature algorithm, the consensus node can adopt the private key share specific to the consensus node to sign the original message containing the specific value of the original transaction list in the consensus to obtain a signature result. Here, the unique value of the original transaction list may be used as the original message for which the signature is intended.

The unique value of the original transaction list may include the original transaction list itself or a hash value of the original transaction list. Block numbers (i.e., numbers) and/or timestamps may also be included in the original message. In addition to the unique value of the original transaction list, the signed object may also include other content, such as the random number seed generated in the previous block, i.e., the original list may also include the random number seed generated in the previous block, which may help the consensus node to confirm whether the previous block is consistent according to the solution of the present specification.

S220: after the consensus nodes collect at least threshold number of the consensus messages, the signature shares of at least threshold number are subjected to a recovery function corresponding to the private key shares generated by the threshold signature algorithm to obtain a complete signature.

As described above, in the application of the threshold signature algorithm, 1 public key pair and n public and private key pairs may be generated, and recovery functions corresponding to the n public and private key pairs may be generated. As mentioned above, the recovery function may recover at least a threshold number of signatures that are verified to be correct to generate a complete signature, and the threshold value of the threshold signature algorithm, i.e. the threshold number, may be set as w. Of course, a complete signature can be generated by the recovery function when there are more than w correct signatures. That is, when the number of correct signatures is greater than or equal to the threshold number w, a complete signature can be generated by the recovery function, and the generated complete signature is determined and will not change due to the number of correct signatures input (as long as the number is greater than or equal to w).

This generated complete signature can be verified for correctness by the 1 total public key. In this way, any node or other device holding the total public key can use the total public key to verify the correctness of the full signature. For example, after the node 1 generates the complete signature, the integrity of the complete signature may be verified by using the total public key, for example, the complete signature is subjected to a cryptographic operation by using the total public key to obtain a first hash, and the original packet is subjected to a hash operation to obtain a second hash, and if the first hash is consistent with the second hash, the integrity of the complete signature may be determined. The integrity includes that the complete signature is for the original message and the original message has not been tampered with. For another example, after the node 1 generates the complete signature, the total public key, and the original packet may be sent to a device outside the block chain, and the device may use the total public key and the original packet to verify the correctness of the complete signature, which is not described in detail in the same principle. The message text here is still the aforementioned content containing the unique value of the original transaction list in this consensus, or further includes the block number and/or the timestamp of the current block and/or the random number seed generated in the previous block.

In the threshold signature algorithm, each consensus node has 1 total public key and 1 private key share and corresponding 1 public key share in n public and private key pairs, which may be generated and distributed by dealer or negotiated by each consensus node, as described above.

nodes

1,2,3 in S210_3，0Where σ is_3，0 Subscript 3 of (a) may indicate a block number, 0 mayTo indicate that this is the signature share for node 0; in S220, node 0 also receives the signature shares σ broadcast by

nodes

Further, node 0 may verify the collected σ with the corresponding public key share_3，0、σ_3，1、σ_3，2Or also comprises c_3，3(or is σ)_3，0、σ_3，1、σ_3，3Or also includes σ_3，2Or is σ_3，1、σ_3，2、σ_3，3Or also includes sigma_3，0Or is σ_3，0、σ_3，2、σ_3，3Or also includes sigma_3，1) The correctness of the operation. In particular, for example, node 0 may employ a corresponding public key share to share σ for the signature_3，1Calculating to obtain a hash value which is recorded as hash_3，1(ii) a Node 0 can also perform the same hash calculation on the original message to obtain hash'_3，1. If hash_3，1And hash'_3，1And the original message is proved to be sent by the node 1 and has not been tampered in the transmission process. Thus, σ_3，1The correctness of the test is verified. Similarly, node 0 may be paired with σ_3，2And the verification is performed, which is not described in detail.

Likewise, node 1 may verify the collected σ with the corresponding public key share_3，o、σ_3，1、σ_3，2Or also includes σ_3，3(or is σ)_3，o、σ_3，1、σ_3，3Or also includes sigma_3，2Or is σ_3，1、σ_3，2、σ_3，3Or also includes sigma_3，0Or is σ_3，0、σ_3，2、σ_3，3Or also includes sigma_3，1) The correctness of the data.

S230: and the consensus node obtains a random number seed based on the complete signature.

Through the steps of S210-S220, the consensus node can normally obtain a complete signature. Thus, based on the complete signature, the consensus node may generate a random number seed using a random number seed generation algorithm. A simpler random number seed generation algorithm is, for example, the sha256 algorithm. Of course, the complete signature can also be used directly as a random number seed.

Through the above process, random number seeds can be generated on the local block chain of the consensus node.

The present specification further provides a method for generating a block header, which may further include, based on the above S210-S230 method: the consensus node puts the obtained random number seed into the block header of the generated current block.

The present specification further provides a method for generating random numbers on a block chain, which may further include, based on the above S210-S230 methods: the consensus node generates a random number based on the generated random number seeds.

As mentioned above, the threshold signature algorithm may employ an RSA-based threshold signature mechanism, an ECDSA-based threshold signature mechanism, a Schnorr-based threshold signature mechanism, or a BLS-based threshold signature mechanism, etc. In the threshold signature algorithm, 1 total public key and n public and private key pairs are generally required to be generated. In a typical and compact implementation, the number of private key shares may be equal to the number of common nodes, each common node holding one of the private keys, i.e. one private key share. In this way, each consensus node signs the original message by using its own private key share based on a threshold signature algorithm to generate a signature share. The minimum number of complete signatures generated by the recovery function, i.e. the threshold number w, may be equal to quorum in the PBFT algorithm, i.e. at least w signature shares may be used by the corresponding recovery function to generate a certain complete signature, regardless of which w of the n signature shares is, as long as the w signatures are signatures made of the same original message using the respective correct private key shares.

In order to implement the threshold signature algorithm on the consensus nodes of the blockchain, a mechanism is required to make n consensus nodes have 1 private key share and 1 corresponding public key share respectively, and all have the same total public key. As mentioned above, the key may be generated by a centralized dealer and distributed to n blockchain consensus nodes, which belongs to a centralized key distribution manner. This centralized key distribution method requires a third party dealer, and requires that the dealer will not be malicious. For example, in the implementation of a Distributed Key Generation (Distributed Key Generation) protocol, it is necessary to generate a polynomial of degree t in principle, then according to a curve formed by the polynomial, take n points above the polynomial, generate n private Key shares through the n points, and distribute the n private Key shares to n participants with threshold signatures. If the process is performed on a dealer, then if the dealer goes bad, the dealer can obtain the private key shares of all n participants, which does not meet the security requirements of the blockchain system.

In addition, there is a decentralized key generation and distribution mode, that is, dealer is cancelled, n public and private key pairs and 1 total public key are obtained by n common nodes through negotiation of a key negotiation process, still each common node separately holds one of n private key shares, and each common node holds the same total public key. This approach, as described above, is traditionally implemented outside the blockchain and relies on network synchronization. The nodes on the blockchain form a distributed network, which is typically semi-synchronous or asynchronous. Therefore, it is unreliable to implement key generation and distribution among nodes of a distributed network outside the blockchain. The realization of reliable distributed key protocol is also an important precondition for generating random number seeds on the block chain.

The aforementioned PBFT protocol belongs to the semi-synchronous (partial synchronization) protocol, which is characterized by assuming that the network is initially asynchronous, but can start synchronizing from a certain time. To have different nodes agree on the same proposal in the network, the simplest way is to set up a master node, which unifies the opinions of the nodes. By setting the timer, the master node can be prevented from making mistakes. In PBFT, if the Normal Case Phase is not completed within a limited time, Backups is triggered to initiate View Change Phase to replace the master node. The PBFT fixes the primary node in one location and all requests can be sent to the primary node first and then broadcast by the primary node to other cognate nodes. In contrast, the honeybadgebft (also often abbreviated HBBFT) algorithm belongs to an asynchronous (asynchronous) protocol. Asynchronous protocols are applicable to asynchronous networks, i.e., messages between nodes in such a network may be arbitrarily delayed, but eventually arrive. The timer is removed from the HoneyBadgerBFT and the execution of the protocol is driven by a message. Meanwhile, all nodes in the HoneyBadgerBFT algorithm are peer-to-peer, and no difference exists between a main node and a backup node, and a process of changing the main node is omitted. Asynchronous network consensus protocols such as HBBFT and the like have no concept of a main node, and all nodes can propose requests and try to construct blocks, so that the asynchronous network protocols relieve the problems of fairness and single-node bottleneck to a certain extent.

For example, chinese patents ZL202111175184.1, ZL202111178795.1, ZL202111178745.3, ZL202111178754.2, ZL202111175144.7, ZL202111175151.7 and chinese patent application CN202111178779.2 propose new consensus algorithms considering the characteristics of semi-synchronous or asynchronous networks of block chain networks.

Through various consensus mechanisms in the block chain network, the overall consistency and synchronization of the block chain network can be guaranteed. For the latter, synchronization of blocks can be achieved as long as the block chain can continue to go out of blocks. Then it will be reliable to implement distributed key generation in conjunction with the blockchain.

The following introduces a method for implementing distributed key generation on a blockchain in this specification, including:

s310: each consensus node generates a unique set of n secret shares, one of which is reserved, and sends n-1 of the secret shares to the other n-1 nodes in an encrypted manner.

The DKG algorithm renumbers nodes starting with 1. Here, the consensus nodes are also numbered starting from 1 in order to be consistent with the DKG algorithm.

An Elliptic Curve (ECC) encryption algorithm is a public key encryption technique, and is based on an Elliptic Curve theory. The encryption, decryption and digital signature are realized by using the discrete logarithm difficulty of an Abel (Abel) group formed by points of an elliptic curve on a finite field. The following description will be given by taking an elliptic curve as an example. Each node may be in group Z_qAnd randomly selecting a t-degree polynomial. The polynomial function of degree N is uniquely determined by N +1 points, because it is finally required that the quorum consensus nodes in the block chain network can recover the signature, and then quorum is N +1, so the degree t of the polynomial is quorum-1. In this way, a complete signature can be obtained by recovering from the quorum (quorum ═ t +1) signature shares through the recovery function. Of course, t may be set to other values. The elliptic curve constructed with this polynomial can be represented as follows:

f_i(z)＝a_i0+a_i1z+a_i2z²+…+a_itz^tformula (1)

In the formula (1), a_i0，a_i1，a_i2，a_i3，...，a_itA polynomial is determined from the set of coefficients for the polynomial.

When the number n of the common nodes in the block chain network is set to 4, and when the quorum of the algorithm such as PBFT and HBBFT is 3, t is 2. In this case, the polynomial equation is:

f_i(z)＝a_i0+a_i1z+a_i22²formula (2)

The node 1 may randomly select a set of numbers from a finite prime field as coefficients, i.e. as a_1C，a₁₁，a₁₂Then the polynomial generated is: f. of₁(z)＝a₁₀+a₁₁z+a₁₂2²。

Similarly, the node 2 may randomly select a set of numbers from the same finite prime number field as coefficients, i.e. as a₂₀，a₂₁，a₂₂Then the polynomial generated is: f. of₂(z)＝a₂₀+a₂₁z+a₂₂2²。

Similarly, the node 3 may randomly select a set of numbers from the same finite prime number field as coefficients, i.e. as a₃₀，a₃₁，a₃₂Then the polynomial generated is: f. of₃(z)＝a₃₀+a₃₁z+a₃₂2²。

Similarly, the node 4 may randomly select a set of numbers from the same finite prime number field as coefficients, i.e. as a₄₀，a₄₁，a₄₂Then the polynomial generated is: f. of₄(z)＝a₄₀+a₄₁z+a₄₂2²。

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

s_ij＝f_i(j) mod q (j ═ 1.., n) formula (3)

In equation (3), q is the same large number used by each node, and is given to f_i(j) The purpose of modulus with q is to divide f_i(j) Is limited to [0, q-1 ]]In the presence of a surfactant. For example:

the consensus node 1 generates 4 secret shares, S each₁₁＝f₁(1)mod q，S₁₂＝f₁(2)mod q，S₁₃＝f₁(3)mod q，S₁₄＝f₁(4) mod q. Here, 4 secret shares, 4, are the total number of consensus nodes. That is, if we want to finally realize that we can generate a complete signature by the recovery function when we take arbitrary w from n signature shares, we need to generate n secret shares. The same applies below.

The consensus node 2 generates 4 secret shares, S each₂₁＝f₂(1)mod q，S₂₂＝f₂(2)mod q，S₂₃＝f₂(3)mod q，S₂₄＝f₂(4)modq。

The consensus node 3 generates 4 secret shares, S respectively₃₁＝f₃(1)mod q，S₃₂＝f₃(2)mod q，S₃₃＝f₃(3)mod q，S₃₄＝f₃(4)mod q。

The consensus node 4 generates 4 secret shares, S each₄₁＝f₄(1)mod q，S₄₂＝f₄(2)mod q，S₄₃＝f₄(3)mod q，S₄₄＝f₄(4)mod q。

Furthermore, each node may exchange other secret shares generated with other consensus nodes over the P2P network, in addition to maintaining one secret share. Specifically, the following may be mentioned:

consensus node 1 reservation S₁₁Will S₁₂Sending S to node 2₁₃Sending to node 3, S₁₄Sent to node 4, and may be sent through a Peer-to-Peer (P2P) network component at the bottom level in the blockchain network. The sent secret share needs to be kept secret, and the consensus node 1 may encrypt the secret share to be sent with a public key of the receiver and then send the encrypted secret share to the receiver, or send the encrypted secret share to the receiver through a secure connection such as TLS (Transport Layer Security).

Consensus node 2 reservation S₂₂Will S₂₁Sending S to the node 1₂₃Sending to node 3, S₂₄Sent to node 4, may be sent through the underlying P2P network component in the blockchain network. Similarly, the sent secret share needs to be kept secret, and the consensus node 2 may encrypt the secret share to be sent with the public key of the receiver and send the encrypted secret share to the receiver, or send the encrypted secret share to the receiver through a secure connection such as TLS.

Consensus node 3 reserves S₃₃A1, S₃₁Sending S to the node 1₃₂Sending S to node 2₃₄Sent to node 4 and may be sent through the underlying P2P network components in the blockchain network. Similarly, the sent secret shares need to be kept secret, and the consensus node 3 may encrypt the secret shares to be sent with the public key of the receiving party and send the encrypted secret shares to the receiving party, or send the encrypted secret shares to the receiving party through a secure connection such as TLS.

Consensus node 4 reserves S₄₄Will S₄₁Sending S to the node 1₄₂Sending S to node 2₄₃Sent to node 3, and may be sent through the underlying P2P network components in the blockchain network. Similarly, the sent secret share needs to be kept secret, and the consensus node 4 may encrypt the secret share to be sent with the public key of the receiver and send the encrypted secret share to the receiver, or send the encrypted secret share to the receiver through a secure connection such as TLS.

Two numbers in the subscript of the visible secret share, the left side may represent the number of the node that issued the secret share, and the right side may represent the node that received the secret share. This is done:

the consensus node 1 locally has secret shares S generated by different nodes₁₁、S₂₁、S₃₁、S₄₁；

The consensus node 2 locally has secret shares S generated by different nodes₁₂、S₂₂、S₃₂、S₄₂；

The consensus node 3 locally has secret shares S generated by different nodes₁₃、S₂₃、S₃₃、S₄₃；

The consensus node 4 locally has secret shares S generated by different nodes₁₄、S₂₄、S₃₄、S₄₄。

Wherein the consensus node 1 has locally S₁₁Is self-generated, co-recognises S that the node 2 has locally₂₂Is self-generated, co-recognises S that the node 3 has locally₃₃Is self-generated, and shares S with the node 4 locally₄₄Is self-generated.

The consensus node preferably signs the secret share to be issued, for example, with its own private key, or uses a MAC (Message Authentication Code) to ensure Message integrity and avoid man-in-the-middle attacks. Accordingly, the node that receives the secret share may verify the correctness of the signature.

S320: each node generates public verification parameters corresponding to the own secret share and broadcasts the public verification parameters through a contract on the chain; the contract on the chain adds the number of the node requesting the broadcast to the first set of nodes.

Each consensus node can generate a set of verification parameters corresponding to its own key share, and the generation method can adopt the following formula:

in equation (4), g is a base point on the elliptic curve. The power of g is also a point on the elliptic curve, depending on the operational nature of the elliptic curve. t is the degree of the polynomial and is typically set to (quorum-1). As mentioned above, if we want to finally realize that we can generate a complete signature by using the recovery function when we take arbitrary w signature shares from n signature shares, we need to set the polynomial degree to t, where t is w-1. The same applies below.

Based on the above formula (4), let t be 2, the consensus node 1 generates a set of verification parameters as<A₁₀,A₁₁,A₁₂>The set of authentication parameters is broadcast via the contract on the chain. Similarly, based on the above formula, the consensus node 2 generates a set of verification parameters as<A₂₀,A₂₁,A₂₂>The set of authentication parameters is broadcast via the contract on the chain. LikeBased on the above formula, the consensus node 3 generates a set of verification parameters as<A₃₀,A₃₁,A₃₂>The set of authentication parameters is broadcast via the contract on the chain. Similarly, based on the above formula, the consensus node 4 generates a set of verification parameters as<A₄₀,A₄₁,A₄₂>The set of verification parameters is broadcast via a contract on a chain.

Based on the nature of cryptography, A_ikIs published without backward pushing to obtain a_ikThus even if published A is obtained from the chain_ikThe polynomial expression in S310 cannot be obtained.

By broadcasting the contract on the chain, specifically, each node can sign a transaction with its own private key and send the transaction to the block chain. Each node may house a blockchain SDK (Software Development kit). The SDK is a collection of a series of program interfaces, documents, paradigms, development tools, and the like. With the built-in SDK, the blockchain link point can initiate transactions to the blockchain network like blockchain clients. The transactions issued by blockchain nodes with their own private key signatures may include calls to smart contracts on blockchains. The called contract is, for example, a DKG contract. This DKG contract may be a system-level contract, i.e., a contract that is pre-deployed on a blockchain, such as a contract created by an account with system administrator privileges, that serves a system-level control function, rather than a contract developed and deployed by the user himself that implements some specific business logic.

Like other contracts, the DKG contract may be executed in a Virtual Machine (e.g., an ethernet Virtual Machine, EVM), or may be executed in a container (e.g., docker), but is not limited thereto. The external account initiates a transaction to the blockchain that calls a contract on the chain, which may trigger execution of the contract. The contents of the transaction include, for example, a from field, a to field, a value field, a data field. The from field may be an account address of a transaction initiator, the to field may represent an address of an intelligent contract being invoked, the value field may be a pass-through native on the blockchain, and the data field may contain methods and parameters for invoking the intelligent contract. By indicating the address of the intelligent contract invoked in the to field, it can be indicated that it is an invocation of an intelligent contract on the blockchain. One or more functions may be generally included in a smart contract, and each function may include some input arguments. A certain function in the intelligent contract to be called can be specified through the data field in the transaction, and parameters needing to be transmitted are filled in the data field.

The result of the execution of the contract may, on the one hand, change the storage of the contract, i.e. the world state of the contract, and on the other hand, the result of the execution of the transaction or relevant information may be recorded in a receipt (receipt) of the blockchain. Specifically, the contract execution result/related information may be represented as an event (event) in the receipt. The structure of the event is, for example, the following format:

Event：

[topic][msg]

......

in the above example, the number of events may be one or more. Each event may include fields for subject (topic) and data (data). The format of the events output when the transaction is executed may be specified in the contract. Through the built-in SDK, the blockchain client or the blockchain link point can monitor the event of a specific topic, pull the content of the corresponding msg when the specific topic event is monitored, and execute preset processing after monitoring the specific topic or some content in the corresponding msg.

Through the event mechanism, the node can store the execution result in the msg corresponding to a certain topic, so that a listener (i.e. a client or a blockchain node of the built-in blockchain SDK) who listens to the topic can obtain the corresponding execution result. In S320, the common verification parameter to be generated by a node may be transferred to the blockchain network by initiating a call to a first function (for example, a function named Broadcast, where the function may include a parameter, and the parameter may include the common verification parameter) in the DKG contract, and one result of the blockchain network executing the transaction is to put the common verification parameter in the msg corresponding to a specific topic in the receipt. Therefore, a node monitoring the topic can obtain the content in the msg field, namely, the public verification parameter. In this way, the contract broadcast on the chain is completed.

The block chain node may be registered by the SDK for events to listen to. Specifically, the blockchain link point may bind a hook function to the generated event in the running blockchain platform code (the hook function may be edited and completed in the development stage together with the platform code). This hook function belongs to a callback function that can be called when a snooped event occurs and can execute certain processing logic. The listening code may include, for example, one or more of a transaction content of a listening blockchain transaction, a contract status of a smart contract, a receipt generated by the contract, and the like. After the block chain node registers the snoop event with the SDK, the block chain node may store a mapping relationship between the snoop event and a listener (for example, a network connection of a client/node that is placed in the SDK and initiates the event snoop, which may generally include information such as an IP address and a port number), for example, a mapping relationship between a certain event for snooping a certain contract and a listener. When the hook function monitors that the corresponding event topic (topic) occurs, the hook function can be called, and then the hook function can inquire the mapping relation and push the monitored event to the network connection. In this way, the SDK initiating the snoop may obtain the snooped event over the maintained network connection. The execution of the contract is also broadcast by implementing the contract on the chain in a similar manner. Specifically, the execution result of the contract and the execution results of other transactions in the block are stored in a transaction result cache region of the block chain node. When all transactions of the blockchain are executed and organized into blocks, the blockchain platform code can monitor receipts in transaction results, and broadcast monitored events to the SDK initiating monitoring. Here, through this listening mechanism, a node may listen for a registered specific topic event and, when such an event occurs, obtain an msg corresponding to this topic event through a maintained connection, thereby obtaining the content in the msg, where the content in the msg includes a common authentication parameter. In short, the broadcast common authentication parameter can be realized through an event mechanism of the block chain, and the reception of the broadcast content can be realized through an event monitoring mechanism.

Thus, the result of broadcasting the common authentication parameters generated by each node over the chain may be as follows:

the consensus node 1 locally has secret shares S generated by different nodes₁₁、S₂₁、S₃₁、S₄₁And verifying the parameters<A₁₀,A₁₁,A₁₂>And can obtain common verification parameters from the chain<A₂₀,A₂₁,A₂₂>，<A₃₀,A₃₁,A₃₂>，<A₄₀,A₄₁,A₄₂>；

The consensus node 2 locally has secret shares S generated by different nodes₁₂、S₂₂、S₃₂、S₄₂And verifying the parameters<A₂₀,A₂₁,A₂₂>And can obtain common verification parameters from the chain<A₁₀,A₁₁,A₁₂>，<A₃₀,A₃₁,A₃₂>，<A₄₀,A₄₁,A₄₂>；

The consensus node 3 locally has secret shares S generated by different nodes₁₃、S₂₃、S₃₃、S₄₃And verifying the parameters<A₃₀,A₃₁,A₃₂>And can obtain common verification parameters from the chain<A₁₀,A₁₁,A₁₂>，<A₂₀,A₂₁,A₂₂>，<A₄₀,A₄₁,A₄₂>；

The consensus node 4 locally has secret shares S generated by different nodes₁₄、S₂₄、S₃₄、S₄₄And verifying the parameters<A₄₀,A₄₁,A₄₂>And can obtain common authentication parameters from the chain<A₁₀,A₁₁,A₁₂>，<A₂₀,A₂₁,A₂₂>，<A₃₀,A₃₁,A₃₂>。

As mentioned above, by broadcasting the contract on the chain, specifically, a transaction may be sent to the blockchain by each node signing with its own private key, for example, a node sends the generated public authentication parameter to the blockchain network by initiating a transaction, for example, invoking a broadcast (r) function in the DKG contract, where the function may include the parameter r, and r may include the public authentication parameter. Broadcast (r) this function execution logic may include, in addition to the above-mentioned placing of the public authentication parameter in the msg corresponding to a particular topic in the receipt, the broadcast (r) function execution logic may also include adding the number of the node requesting broadcast to the first node set, i.e., the aforementioned storage of the change contract, i.e., the change contract's world state. Assuming that the consensus nodes 1-4 each send a transaction calling the broadcast (r) function in the DKG contract, respectively, the execution result of the broadcast (r) function includes storing the numbers 1-4 of the 4 consensus nodes initiating the transaction in a first state maintained by the contract, e.g., in the form of {1,2,3,4}, { } represents a set, e.g., named partitions set.

S330: each consensus node verifies each received secret share and the corresponding public verification parameter, and sends the node number failed in verification to the contract through the complaint transaction; the contract determines a second node set according to the node number which fails in verification sent by each consensus node and the first node set.

Each consensus node may receive secret shares from any other node and receive common authentication parameters broadcast by contracts on the chain.

As mentioned in S310 above, each consensus node generates n secret shares S_ijAnd keeping one share by itself, and sending n-1 secret shares to other n-1 nodes through P2P network components and encryption respectively. As mentioned in S320, each node generates a public verification parameter corresponding to its own secret share and broadcasts the public verification parameter through the contract on the chain.

If the secret shares issued by each node and the corresponding common authentication parameters are attributed to the same polynomial, the following equation should hold:

as previously mentioned, t ═ quorum-1; when n is 4, quorum is 3, and t is 2.

Based on such properties of equation (5), each secret share and common authentication parameter received can be authenticated with this equation. If the verification equation is true, the secret shares and the corresponding public verification parameters are attributed to the same polynomial, otherwise they are not attributed to the same polynomial. This also allows verifying whether the node generating the secret share and corresponding public authentication parameters is behaving wrongly. Typical behavior is for example that a node generates S from a first polynomial_ijBut generated A with a different polynomial_ik(k＝0,...,t)。

The verification specifically includes:

when j is 1, the consensus node 1 may verify the following:

i＝1：

(in fact, the consensus node 1 may not verify whether this equation holds, since the secret share S₁₁And verification parameters<A₁₁,A₁₂,A₁₃>Are all self-generated)

i＝2：

i＝3：

i＝4：

If the equation corresponding to i-2 does not hold, the consensus node 1 may send the node number 2 that fails the authentication to the DKG contract. Similarly, if the equation corresponding to i-2 and 3 does not hold, the consensus node 1 may send the

node numbers

2 and 3 that fail the authentication to the DKG contract. Similarly, if the corresponding equation for i ═ 2,3, and 4 does not hold, the consensus node 1 may send the

node numbers

2,3, and 4 that failed the authentication to the DKG contract.

When j equals 2, i.e. the consensus node 2 may verify the following:

i＝1：

i＝2：

(in fact, the consensus node 2 may not verify whether this equation holds, since the secret share S₂₂And verification parameters<A₂₀,A₂₁,A₂₂>Are all self-generated)

i＝3：

i＝4：

If the equation corresponding to i ═ 1 does not hold, the consensus node 2 can send the node number 1 that failed the authentication to the DKG contract. Similarly, if the equation corresponding to

i

1 and 3 does not hold, the consensus node 2 may send the

node numbers

1 and 3 that fail the authentication to the DKG contract. Similarly, if the equation corresponding to

i

1, 3, and 4 does not hold, the consensus node 2 may send the

node number

1, 3, and 4 that fails the authentication to the DKG contract.

When j is 3, the consensus node 3 may verify the following:

i＝1：

i＝2：

i＝3：

(in fact, the consensus node 3 may not verify whether this equation holds, since the secret share S₃₃And verification parameters<A₃₀,A₃₁,A₃₂>Are all self-generated)

i＝4：

If the equation corresponding to i ═ 1 does not hold, the consensus node 3 can send the node number 1 that failed the authentication to the DKG contract. Similarly, if the equation corresponding to

i

1 and 2 does not hold, the consensus node 3 may send the

node numbers

1 and 2 that fail the authentication to the DKG contract. Similarly, if the equation corresponding to

i

1,2, and 4 does not hold, the consensus node 3 may send the

node number

1,2, and 4 that fails the authentication to the DKG contract.

When j is 4, the consensus node 4 may verify the following:

i＝1：

i＝2：

i＝3：

i＝4：

(in fact, the consensus node 4 may not verify whether this equation holds, since the secret share S₄₄And verification parameters<A₄₀,A₄₁,A₄₂>Are all self-generated)

If the equation corresponding to i ═ 1 does not hold, the consensus node 4 can send the node number 1 that failed the authentication to the DKG contract. Similarly, if the equation corresponding to

i

1 and 2 does not hold, the consensus node 4 may send the

node number

1 and 2 that fails the authentication to the DKG contract. Similarly, if the equation corresponding to

i

1,2, and 3 does not hold, the consensus node 4 may send the

node number

1,2, and 3 that fails the authentication to the DKG contract.

A transaction may be signed by each node with its own private key and sent to the blockchain network, for example, a node sends a node number that failed authentication to the blockchain network by initiating a transaction, such as a complaint transaction, which may call the function confirm (r) in the DKG contract, where the function may include a parameter r, which may include the node number that failed authentication submitted by the node in the complaint transaction.

The execution logic of the confirm (r) function may include copying node numbers of the first set of nodes that did not receive complaint transactions to the second set of nodes. Assuming that the first node set Parties is {1,2,3,4}, but the node number included in the complaint transaction received by the DKG contract is 4, for example, if the parameter r included in the function calling confirm (r) in the complaint transaction initiated by the consensus node 1 is 4, the DKG contract marks the node number 4 in the first node set Parties as deleted. Assuming that no other node numbers in the other first node set Parties receive corresponding complaints, the

node numbers

1,2 and 3 in the first node set are still reserved. Thus, the DKG contract may determine a second set of nodes {1,2,3} based on the authentication failure node number 4 from each cognizant node and the first set of nodes {1,2,3,4}, for example, named QUAL.

It should be noted that, in a blockchain network, due to the semi-synchronous or asynchronous network characteristics, the execution of contracts is not necessarily performed in the same block, but may be performed in different blocks. In this case, the state machine may be generally configured in the reengineering to transition the state of the state machine after a portion of the execution, or until the state machine transitions to some final state. Each step executed by the state machine may be executed and triggered upon receipt of a transaction. Thus, the DKG contract in this step determines the set of nodes, possibly extending over multiple blocks.

S340: each consensus node calculates a public key share based on the verification parameters and the second node set, and calculates a corresponding private key share based on the local secret share and the second node set.

In one aspect, each consensus node may each locally compute a public key share based on the authentication parameters and the second set of nodes, which may be computed according to the following equation:

thus, for example, the second set of nodes is: {1,2,3,4}, the public key share computed by consensus node 1 may be:

similarly, for example, the public key share computed by the consensus node 2 may be:

similarly, for example, the public key share computed by the consensus node 3 may be:

similarly, for example, the public key share computed by the consensus node 4 may be:

on the other hand, each consensus node calculates its corresponding private key share based on the local secret share and the second node set, which can be calculated according to the following formula:

x_j＝∑_i∈QUAL s_ijmod q equation (7)

For example, the consensus node 1 locally computes its private key share:

the consensus node 2 locally computes its private key share:

the consensus node 3 locally computes its own share of the private key:

the consensus node 4 locally computes its own share of the private key:

it can be seen that the private key shares calculated by the node 1, the node 2, the node 3 and the node 4 are different.

On the other hand, each of the consensus nodes may locally calculate an overall public key based on the verification parameter and the second node set, and the overall public key may be calculated according to the following formula:

y＝∏_i∈QUAL y_iformula (8)

Wherein, y_i＝A_i0。

Thus, for example, the consensus node 1 may calculate the total public key as:

y＝y₁*y₂*y₃*y₄＝A₁₀*A₂₀*A₃₀*A₄₀

similarly, for example, the consensus node 2 may calculate the total public key as:

y＝y₁*y₂*y₃*y₄＝A₁₀*A₂₀*A₃₀*A₄₀

similarly, for example, the consensus node 3 may calculate the total public key as:

y＝y₁*y₂*y₃*y₄＝A₁₀*A₂₀*A₃₀*A₄₀

similarly, for example, the consensus node 4 may calculate the total public key as:

y＝y₁*y₂*y₃*y₄＝A₁₀*A₂₀*A₃₀*A₄₀

it can be seen that the total public keys calculated by the node 1, the node 2, the node 3 and the node 4 are the same, that is, by the above method, each node obtains the same total public key.

The above private key share x₁With public key share pub₁Corresponding, private key share x₂With public key share pub₂Corresponding, private key share x₃With public key share pub₃Corresponding, private key share x₄With public key share pub₄And (7) corresponding. As previously described, each public key share can verify the signature share made by the corresponding private key share. Moreover, a complete signature, which is recovered by a recovery function, of at least the quotients of the signature generated by the quotients of the qurum private key can be verified by the corresponding 1 total public key.

For another example, the second node set is: {1,2,3}, the public key share computed by consensus node 1 may be:

it can be seen that, assuming that the 4 th node is malicious, the secret shares and the corresponding public verification parameters are not generated according to the same polynomial, and thus the verification by at least one node fails and complaints are made, the node 4 is not included in the second node set, and the public key shares are calculated by at least the 1 st, 2 nd and 3 th nodes not according to the public verification parameters generated by the node 4 but according to the public verification parameters generated by the

nodes

1,2 and 3 in the second node set.

Each consensus node calculates its corresponding private key share based on the local secret shares and the second set of nodes.

For example, the consensus node 1 locally computes its private key share:

the consensus node 2 locally computes its private key share:

the consensus node 3 locally computes its own share of the private key:

the consensus node 4 locally computes its own share of the private key:

it can be seen that, assuming that the 4 th node is malicious, the secret shares and the corresponding public verification parameters are not generated according to the same polynomial, and thus the verification by at least one node fails and complaints are made, the node 4 is not included in the second node set, and at least the 1 st, 2 nd and 3 th nodes do not calculate the secret shares according to the secret shares generated by the node 4, but according to the secret shares generated by the

nodes

1,2 and 3 in the second node set. Moreover, at least the private key shares calculated by the node 1, the node 2 and the node 3 are different.

Each consensus node may each locally compute an overall public key based on the authentication parameters and the second set of nodes.

Thus, for example, the consensus node 1 may calculate the total public key as:

y＝y₁*y₂*y₃＝A₁₀*A₂₀*A₃₀

it can be seen that, assuming that the 4 th node is malicious, the secret shares and the corresponding public verification parameters are not generated according to the same polynomial, and thus the verification by at least one node fails and complaints are initiated, the node 4 is not included in the second node set, and the process of calculating the total public key by at least the 1 st, 2 nd and 3 th nodes does not depend on the public verification parameters generated by the node 4, but depends on the public verification parameters generated by the

nodes

1,2 and 3 in the second node set. Moreover, the total public keys calculated by at least the node 1, the node 2 and the node 3 are the same, that is, the same total public key is obtained by at least the honest nodes by the method.

Thus, for a consensus node with a total number n, using a threshold signature algorithm, where it is expected that any at least w signature shares of the m signature shares can be recovered to obtain a complete signature, if there is no rogue node, i.e. the secret shares and the corresponding public verification parameters are generated according to the same polynomial, then n may be equal to m. If there are rogue nodes, for example, there are b rogue nodes, then m is n-b, and w remains unchanged, but m needs to be ensured not to be less than w, otherwise the threshold signature algorithm fails.

As mentioned in S330, each consensus node verifies each received secret share and the corresponding public verification parameter, and if the verification fails, the verification node may sign a complaint transaction with its own private key and send the complaint transaction to the block chain. Specifically, the transaction may call a confirm (r) function in the DKG contract, where the function may include a parameter r and r may include a node number of a failed verification submitted by a node in the complaint transaction. For example, node j receives secret share S sent by node i encrypted in S310_ijS sent by receiving node j to i_ijThe verification is performed using equation (5). A typical case of failed authentication is S sent by node i_ijDoes not correspond to a common authentication parameter generated by node i and broadcast by a contract on the chain, then this secret share S is received_ijMay be verified in S330 and the number i of this node may be sent to the DKG contract after the verification fails. In order to prove that the secret share sent by node i has not been tampered with, node j may send the secret share of node i and the signature to the DKG contract in addition to sending the number i of this node. It is also mentioned in the foregoing S310 that the node may perform the generation and sending of secret sharesAnd (6) signing. In order to enable the DKG contract to verify the secret share and the corresponding public verification parameter, it is necessary to include the plaintext of the secret share in the complaint transaction, i.e., the plaintext obtained by node j decrypting the encrypted secret share of node i. In order to enable the DKG contract to verify the signature, it is preferable that the node i signs the secret share first in S310, and the secret share in plain text and the signature are encrypted and then sent to the node j, that is, the consensus node that generated the secret share signs the generated secret share and encrypts and sends the secret share to other nodes. In this way, the complaint transaction sent by the node j to the DKG contract includes, in addition to the number of the node i, the plain-text secret share sent by the node i to the node j and the signature generated by the generator i on the plain-text secret share.

Before the DKG contract determines the second node set according to the node number that fails to be verified sent by each consensus node and the first node set, the DKG contract may first verify the signature of the secret share in the complaint transaction, and if the verification is correct, the secret share originally sent by the node i to the node j in the above example may be confirmed without being tampered. Further, the DKG contract may verify whether the secret share and the corresponding public verification parameter belong to the same polynomial, such as according to equation (5) above. If the verification equation is not established according to formula (5), it can be confirmed that the secret share and the corresponding public verification parameter do not belong to the same polynomial, and then the complaint is established; if the equation is verified to be valid according to equation (5), it can be confirmed that the secret share and the corresponding common verification parameter are verified to belong to the same polynomial, and the complaint is not true. For complaints being true, i.e., validation failed, the DKG contract may determine the second set of nodes based on the node number in the complaint transaction and the first set of nodes. For example, if the complaint transaction includes node number 4, then the DKG contract may mark the node number 4 in the first node set Parties as deleted, as in the example described above, and the first node set Parties ═ {1,2,3,4 }. Further, the DKG contract may determine the second set of nodes QUAL {1,2,3} from the node number 4 and the set of partites {1,2,3,4} for which authentication failed. Whereas for complaints that are not true, i.e., that the authentication fails cannot be confirmed, the DKG contract does not mark the node number 4 in the first set of nodes Parties as deleted, nor will the QUAL be set to {1,2,3} accordingly, but rather still maintain {1,2,3,4 }.

Furthermore, it is possible that during the previous distributed key generation process, the secret share sent by the node i to the node j does not coincide with the public verification parameter generated by the corresponding node i, so that the complaint transaction of the node j to the node i is successful, while during the next distributed key generation process, the secret share sent by the node i to the node j actually coincides with the public verification parameter generated by the corresponding node i. In this case, in the latter round, node j can still initiate a complaint transaction with the plaintext secret shares and signatures of node i of the previous round, thereby misjudging the DKG contract in the latter round. This is obviously a malicious complaint. For this reason, in each round of distributed key generation, a sequence number, e.g., epoch, indicating the round of distributed key generation may be included in the initiated transaction. Each new round of distributed key generation, epoch may be incremented by 1 based on the original value. Thus, in S310, the secret share and the epoch generated and transmitted by the node i may be signed together and then encrypted. Furthermore, in the distributed key generation process of epoch ═ p, if the node i is malicious, the node j can send the number of the node i which fails to verify and the secret share of the plaintext which is sent to the node j by the node i, the epoch ═ p and the signature through the complaint transaction, so that the DKG contract can verify after receiving the complaint transaction, and can verify the secret share of the plaintext in the original message through the signature, and the epoch ═ p is not tampered. Thus, in the process of generating the distributed key with the epoch being p +1, assuming that the node i is not malicious, even if the node j sends the serial number of the node i which fails to verify through the complaint transaction, the secret share of the plaintext which is sent to the node j by the node i, the epoch being p +1 and the signature of the previous round, the signature of the previous round cannot be matched with the original message because the signature of the previous round is specific to the epoch being p, so that the DKG contract can firstly verify that the original message is tampered without trusting the complaint after receiving the complaint transaction through the signature, thereby avoiding malicious complaints.

It should be noted that the sending of the plaintext secret shares in S330 is performed on the premise that the honest nodes must respond correctly within a certain time. In this way, private key shares are not leaked due to sending of all secret shares, and a final complete signature is not leaked.

At S320, the round is also accompanied by the common authentication parameters broadcast by each consensus node through the contract on the chain. In this way, the rounds to which the common authentication parameter belongs can be distinguished in the presence of delays in the network.

By the method, on the basis that a consensus mechanism guarantees the overall consistency and synchronization of the blockchain network, the generation of the distributed key is realized by combining a blockchain intelligent contract, so that the generation of the distributed key is guaranteed to be generated by cooperation of all participants on the one hand, and the generated result is consistent and reliable on the other hand, the strong dependence of the distributed key generation realized outside the original blockchain on network synchronization is eliminated, and the problem of unreliability of the generated result under the condition is solved.

On one hand, in the method embodiment shown in fig. 7, the nodes are required to cooperate together to complete the distributed key generation process. In particular, in the initial step, for example, in S310 described above, each consensus node needs to generate a unique set of n secret shares from a similar point in time, and each consensus node may keep itself one secret share and send n-1 secret shares to other n-1 nodes in an encrypted manner.

On the other hand, the scheme provided by the specification is on the premise that honest nodes can certainly make correct responses within a certain time. The predetermined time may be implemented by a timer. This timer may be maintained by a physical or logical entity other than the contract. The former is, for example, a physical entity other than the blockchain node, and the latter is, for example, an independent process other than the blockchain platform process running on the blockchain node or a thread or coroutine in the blockchain platform process. For convenience, this physical or logical entity is collectively referred to herein as a DKG controller.

In both aspects, the DKG controller maintains a timer that needs to be triggered by an activation signal. The start signal may be a received system command or an event on the received blockchain. The former is, for example, a system command issued by an account with administrator authority, and the latter is, for example, a specific event on some blockchain. For the case of events on the receive blockchain, the DKG controller may listen for a specific topic in the receipt, obtaining specific events and msg content, the principle as described above. Thus, the method in fig. 7/8 can be started after the DKG listens for the activation signal.

The example is described below in which the DKG controller is a thread or coroutine in a blockchain platform process, and the DKG controller receives events on the blockchain. Here, it is still assumed that the blockchain network includes 4 common nodes, which are numbered 1,2,3, and 4, respectively.

After the DKG controller (hereinafter referred to as DKG controller 1) on node 1 receives the start signal, it can issue a transaction with the private key of node 1, and the transaction can invoke a DKG contract. This startup transaction that calls the DKG contract may specifically be a call to the dkstart () function, meaning that the distributed key generation process of this round is started. The execution logic of the dkstart () function may include adding 1 to the value of epoch after the dkstart () function is called. Also, after the contract is executed, an event for a particular topic may be generated in the receipt and this epoch may be added to the corresponding msg. As described above, in each round of various initiated transactions, such as the epoch carrying the round, on one hand, the round to which the transaction belongs can be distinguished, for example, the round to which the common authentication parameter belongs can be distinguished, and on the other hand, malicious complaints can be avoided.

The DKG controller 1 may register a snoop event to a block link point in order to subscribe to a particular topoc's event. Upon hearing the relevant event, the DKG controller 1 may determine that the previously initiated transaction invoking the dkstart () contract has been executed and may obtain the current epoch value from the receipt. Thus, the DKG controller 1 can start a timer. This timer may be a timer that counts the number of outgoing blocks, or more precisely, counts the number of blocks generated on the block chain. The starting point for starting the timer may be the block number of the block for which the transaction that called the dkstart () contract was performed. The DKG controller 1 may set a timeout for the timer it maintains (subsequently referred to as timer 1), which is for example a certain number of blocks, for example 10 blocks, indicating a block number starting from the starting block number plus 10. For example, DKG controller 1 listens from the chain of blocks that a transaction that previously initiated a call to the dkstart () contract was executed in block No. 100, then timer 1 may be started. The timer 1 starts counting from the 100 th block and takes 10 blocks as the timeout time, i.e. until the 110 th block is generated as the timeout.

After the DKG controller 1 starts the timer 1, the polynomial may be generated as described in S310, and then 4 secret shares S11, S12, S13, and S14 may be generated (of course, the polynomial, the secret shares, and the common authentication parameter may also be generated before starting the timer 1, and the subsequent operations are similar and are not repeated). The DKG controller 1 may reserve S itself₁₁And the other three secret shares are respectively sent to the other 3 consensus nodes through the encryption of the P2P network component. For example, S₁₂To node 2, S₁₃To the node 3, S₁₄And sent to node 4.

In addition, the node 1 may also generate a public verification parameter corresponding to its own secret share and broadcast it through the contract on the chain, as described in S320.

The DKG controller 1 can listen to the block chain for an out-of-block condition. The block chain network runs continuously, new blocks are generated continuously, and 1 is added to the corresponding block numbers. The DKG controller 1 may keep listening for the current latest block number.

The DKG controller 2 at node 2 may also listen for receipts and, after listening for an event that the transaction of the dkstart () contract has been executed, may obtain the current epoch value from the receipt. Further, the DKG controller 2 may start the timer 2. For example, the DKG controller 2 listens from the block chain to the dkstart () contract of the latest epoch executing in block No. 100, then timer 2 may be started. The timeout time is uniformly set to 10 blocks, for example. The timer 2 starts counting from block number 100 and takes 10 blocks as the timeout time, i.e. until block number 110 is generated as the timeout.

After the DKG controller 2 starts the timer 2, the polynomial may be generated as described in S310, and S with 4 secret shares may be generated₂₁，S₂₂，S₂₃And S₂₄. The DKG controller 2 may reserve S itself₂₂And the other three secret shares are respectively sent to the other 3 consensus nodes through the encryption of the P2P network component. For example, S₂₁To node 1, S₂₃To the node 3, S₂₄To be sent to the node 4. In addition, the node 2 may also generate a public verification parameter corresponding to its own secret share and broadcast it through the contract on the chain, as described in S320.

Similarly, the DKG controller 3 on node 3 may also listen for receipts and, after listening for an event that the transaction of the dkstart () contract has been executed, may obtain the current epoch value from the receipt. Further, the DKG controller 3 may start the timer 3. For example, the DKG controller 3 listens from the block chain to the dkstart () contract of the latest epoch executing in block No. 100, then the timer 3 may be started. The timeout time is uniformly set to 10 blocks, for example. The timer 3 starts counting from block number 100 and takes 10 blocks as the timeout time, that is, until block number 110 is generated as the timeout.

After the DKG controller 3 starts the timer 3, the polynomial may be generated as described in S310, and S of 4 secret shares may be generated₃₁，S₃₂，S₃₃And S₃₄. The DKG controller 3 may reserve S itself₃₃And the other three secret shares are respectively sent to the other 3 consensus nodes through the encryption of the P2P network component. For example, S₃₁To node 1, S₃₂To node 2, S₃₄And sent to node 4. In addition, the node 3 may also generate a public verification parameter corresponding to its own secret share and broadcast it through the contract on the chain, as described in S320.

Similarly, the DKG controller 4 at the node 4 may also listen for receipts and, after listening for an event that the transaction of the dkstart () contract has been executed, may obtain the current epoch value from the receipt. Further, the DKG controller 4 may start the timer 4. For example, the DKG controller 4 listens from the block chain to the dkstart () contract of the latest epoch executing in block No. 100, then the timer 4 may be started. The timeout time is uniformly set to 10 blocks, for example. The timer 4 starts counting from block number 100 and takes 10 blocks as the timeout time, i.e. until block number 110 is generated as the timeout.

After the DKG controller 4 starts the timer 4, the polynomial may be generated as described in S310, and S of 4 secret shares may be generated₄₁，S₄₂，S₄₃And S₄₄. The DKG controller 4 may reserve S itself₄₄And the other three secret shares are sent to the other 3 consensus nodes, respectively, encrypted by the P2P network component. For example, S₄₁To node 1, S₄₂To node 2, S₄₃And sent to node 3. In addition, the node 4 may also generate a public verification parameter corresponding to its own secret share and broadcast it via the contract on the chain, as described in S320.

The specific process of broadcasting the public authentication parameters via the contract on the chain may be that each node signs a transaction with its own private key to the blockchain, as described above. Here, for example, the transaction calls the Broadcast () function in the DKG contract, with the incoming parameters including the public authentication parameters generated by the node itself and the epoch.

For example, DKG controller 1 listens from the chain of blocks that a transaction that previously initiated a call to the dkstart () contract is executed in block No. 100, starting timer 1. Further, after the DKG controller 1 generates the secret share and the corresponding common authentication parameter, S is added₁₂Sending S to node 2 through P2P network component₁₃Sending S to node 3 through P2P network component₁₄The network component sends to node 4 through P2P and initiates a transaction to invoke a Broadcast () function, the incoming parameters including the common authentication parameters generated by the DKG controller 1 itself and the current epoch. Further, the result of the execution of the Broadcast () function may include adding the number of node 1 to the Parties set. The transaction in which the Broadcast () function is executed, for example, in block 102, the execution result includes Parties ═ 1.

As mentioned above, after the DKG controller 1 of the node 1 receives the start signal, it can issue a transaction with the private key of the node 1 to call the dkstart () function. The dkstart () function may generate a corresponding receipt upon execution. Further, the

nodes

1,2,3,4 may listen for receipts and start the distributed key generation process of this round after listening for the corresponding event in the receipt. It should be noted that in this process, the DKG controller 2 of the node 2 may also receive the start signal, and accordingly, the node 2 also initiates a transaction to call the dkstart () function in the DKG contract. At this point, the dkstart () function of the current round has already been executed, and the distributed key generation process of the current round may not have yet ended. Therefore, it is not reasonable for the DKG () function to start again and should be avoided. A state may be set in the dkstart () function, which may be False if the distributed key generation process of the current round has ended, or True if the distributed key generation process of the current round is in progress. The node 1 issues a transaction with the private key of the node 1 to call the DKGStart () function, and if the state in the DKGStart () function is False, the distributed key generation process of the current round can be started and started, and the state is changed to True. Furthermore, after receiving a call request initiated by the node 2 to start the distributed key generation process of the current round, the subsequent DKGStart () function checks that the current state is True, thereby stopping processing the call request. Subsequently, when the distributed key generation process of the current round is finished, the state can be changed to False. In this way, before the distributed key generation process of the current round is finished, the transaction which is sent by other nodes and starts the distributed key generation process can be stopped. In addition, before the distributed key generation process of the current round is finished, the transaction sent by other nodes to start the distributed key generation process can be stopped, and the epoch can be the same as or different from the epoch of the ongoing distributed key generation process. In this way, it is avoided whether the node 2 intends to start the same round of distributed key generation or a new round or other different ethical distributed key generation.

As mentioned above, the timer that initiates the maintenance of the DKG controller may be triggered by an enable signal. The start signal may be a received system command or an event on the received blockchain. The former is, for example, a system command issued by an account with administrator authority, and the latter is, for example, a specific event on some blockchain. The specific event may include a change of the consensus node and/or a change of the state of the consensus node in the node management contract. The change of consensus node may comprise an addition and/or an exit of a consensus node. The state change of the consensus node may include that the non-consensus node is changed into the consensus node, the consensus node is changed into the non-consensus node, the consensus node is changed from the normal working state into the other state or from the other state into the normal working state, and the like. Typically, if a new consensus node joins, the distributed key generation process should be restarted between all consensus nodes including the new consensus node, so that the newly joined consensus node has a DKG private key share and a public key share, so that the newly joined consensus node can subsequently get the same random number seed as the other consensus nodes, so that a transaction involving a random number can be performed in the transaction execution stage. Other cases are similar and will not be described in detail.

Through the embodiment, each node can start the distributed key generation process approximately synchronously, so that the distributed key generation process of the same round is completed cooperatively.

The addition/deletion of the consensus nodes and the node state change can be realized in a chain in a contract mode. Chinese patent publications such as CN110730204A, CN110727731A, CN111183625A, CN113067896A, and CN113067894A describe addition/deletion of common nodes and modifications thereof. Thus, the DKG controller can be notified in an event mode, and the distributed key generation process described above is started.

The following describes a method for implementing distributed key generation on a blockchain in a perspective of one consensus node in conjunction with fig. 8, including:

s410: the first node receives the secret share generated and encrypted by other nodes, and receives the corresponding public verification parameter through contract broadcasting on the chain; the contract adds the number of the node requesting broadcasting to the first node set;

s420: the first node verifies each received secret share and the corresponding public verification parameter, and sends the node number failed in verification to the contract through complaint transaction; the contract determines a second node set according to the node number which fails in verification and is sent by each consensus node and the first node set;

s430: the first nodes respectively calculate public key shares based on the verification parameters and the second node set, and calculate corresponding private key shares based on the local secret shares and the second node set.

Wherein the encrypted secret shares received by the first node may further comprise signed and encrypted secret shares.

The complaint transaction can also comprise a plaintext secret share generated by a generator and a signature of the plaintext secret share by the generator.

Before the contract determines the second node set according to the node number of the verification failure sent by each consensus node and the first node set, the method may further include:

the contract verifying a signature of the secret share in the complaint transaction;

after the contract verifies that the signature of the secret shares is correct, the secret shares and corresponding public verification parameters are also verified.

Wherein the encrypted secret shares received by the first node may further comprise secret shares signed and encrypted along with a number representing a round of distributed key generation.

The complaint transaction may further include the secret share of the plaintext generated by the generator, the round, and the signature of the generator on the secret share of the plaintext and the round.

Before the contract determines the second node set according to the node number which fails in verification sent by each consensus node and the first node set, the method may further include:

the contract verifying the signature of the secret shares and rounds in the complaint transaction;

after the contract verifies that the secret shares and the signature of the round are correct, the secret shares and corresponding public verification parameters are also verified.

Wherein the round is also accompanied by the common authentication parameters received by the first node via the contract on the chain.

And the contract verifies the secret shares and the corresponding public verification parameters, and after the verification is confirmed to fail, a second node set can be determined according to the node numbers in the complaint transactions and the first node set.

And the first node can also calculate a public key share total public key based on the verification parameters and the second node set.

An embodiment of the present disclosure further provides a blockchain system, including a plurality of common nodes, where:

And the generated starting event comprises the sequence number of the current round.

And the sequence number of the current round is increased progressively on the basis of the sequence number of the previous round.

After the distributed key generation process is started, each consensus node sends the transaction of the distributed key generation contract to the distributed key generation contract, wherein the transaction comprises the sequence number of the current round.

Wherein each consensus node on the blockchain generates a polynomial, a secret share, and a public authentication parameter before or after initiating the distributed key generation process.

After the distributed key generation contract receives the transaction for starting the distributed key generation process sent by the first node, the transaction for starting the distributed key generation process sent by other nodes is stopped before the distributed key generation process of the current round is finished.

And stopping processing the transaction for starting the distributed key generation process sent by the other node, wherein the transaction for starting the distributed key generation process sent by the other node and the transaction for starting the distributed key generation process sent by the other node are the same as or different from the round.

Wherein the predetermined event comprises a change of a consensus node and/or a change of a state of the consensus node in a node management contract.

Wherein the change of the consensus node comprises the addition and/or the exit of the consensus node.

The state change of the consensus node comprises the steps that the non-consensus node is changed into the consensus node, the consensus node is changed into the non-consensus node, and the consensus node is changed into the other state from the normal working state or is changed into the normal working state from the other state.

In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD) (e.g., a Field Programmable Gate Array (FPGA)) is an integrated circuit whose Logic functions are determined by a user programming the Device. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to the software compiler used in program development, but the original code before compiling is also written in a specific Programming Language, which is called Hardware Description Language (HDL), and the HDL is not only one kind but many kinds, such as abel (advanced boot Expression Language), ahdl (alternate Language Description Language), communication, CUPL (computer universal Programming Language), HDCal (Java Hardware Description Language), langa, Lola, mylar, HDL, PALASM, rhydl (runtime Description Language), vhjhdul (Hardware Description Language), and vhygl-Language, which are currently used commonly. It will also be apparent to those skilled in the art that hardware circuitry for implementing the logical method flows can be readily obtained by a mere need to program the method flows with some of the hardware description languages described above and into an integrated circuit.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, 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, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be considered a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a server system. Of course, this description does not exclude that, as future computer technology advances, the computer implementing the functionality of the above-described embodiments may be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular telephone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

Although one or more embodiments of the present description provide method operational steps as described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive approaches. The order of steps recited in the embodiments is merely one manner of performing the steps in a multitude of orders and does not represent the only order of execution. When an actual apparatus or end product executes, it may execute sequentially or in parallel (e.g., parallel processors or multi-threaded environments, or even distributed data processing environments) according to the method shown in the embodiment or the figures. The terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in a process, method, article, or apparatus that comprises the recited elements is not excluded. For example, if the terms first, second, etc. are used to denote names, they do not denote any particular order.

For convenience of description, the above devices are described as being divided into various modules by functions, and are described separately. Of course, when implementing one or more of the present description, the functions of each module may be implemented in one or more software and/or hardware, or a module implementing the same function may be implemented by a combination of multiple sub-modules or sub-units, etc. The above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is only one type of logical functional division, and other divisions may be realized in practice, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The description has been presented with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the description. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may 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, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

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

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

As will be appreciated by one skilled in the art, one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of the present description may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

One or more embodiments of the present description may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. One or more embodiments of the present specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

All the embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment. In the description of the specification, reference to the description of the term "one embodiment," "some embodiments," "an example," "a specific example," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the specification. In this specification, the schematic representations of the terms used above are not necessarily intended to refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, various embodiments or examples and features of different embodiments or examples described in this specification can be combined and combined by one skilled in the art without contradiction.

The above description is merely exemplary of one or more embodiments of the present disclosure and is not intended to limit the scope of one or more embodiments of the present disclosure. Various modifications and alterations to one or more embodiments described herein will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement or the like made within the spirit and principle of the present specification should be included in the scope of the claims.

Claims

1. A method of initiating a distributed key generation process on a blockchain, comprising:

a first common identification node on the block chain monitors a system instruction or a predetermined event on the block chain, and initiates a transaction for starting a distributed key generation process to a distributed key generation contract after monitoring;

2. The method of claim 1, wherein the generated start event comprises a sequence number of a current round.

3. The method of claim 2, wherein the sequence number of the current round is incremented on the basis of the sequence number of the previous round.

4. The method of claim 2, wherein each consensus node sends the transaction for the distributed key generation contract to include the sequence number for the current round after the distributed key generation process is initiated.

5. The method of claim 1, each consensus node on a blockchain generates a polynomial, a secret share, and a common authentication parameter before or after initiating the distributed key generation process.

6. The method of claim 1, wherein the distributed key generation contract stops processing transactions sent by other nodes to start the distributed key generation process before the distributed key generation process is finished in the current round after receiving the transaction sent by the first node to start the distributed key generation process.

7. The method of claim 6, wherein stopping processing transactions sent by other nodes that initiate the distributed key generation process comprises stopping processing transactions sent by other nodes that initiate the distributed key generation process that are the same or different from the round.

8. The method of claim 1, wherein the predetermined event comprises a change in a consensus node and/or a change in a consensus node status in a node management contract.

9. The method of claim 8, wherein the change of consensus node comprises an addition and/or an exit of a consensus node.

10. The method as claimed in claim 8, wherein the change of the status of the consensus node comprises a transition from a non-consensus node to a consensus node, a transition from a consensus node to a non-consensus node, a transition from a normal operation status to another status, or a transition from another status to a normal operation status.

11. A blockchain system comprising a plurality of consensus nodes, wherein: