CN114640450B

CN114640450B - Method and system for realizing retransmission of secret share and determining failure node on block chain

Info

Publication number: CN114640450B
Application number: CN202210323899.5A
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: 2024-06-14
Anticipated expiration: 2042-03-29
Also published as: CN114640450A

Abstract

A method and system for realizing distributed key generation on a blockchain comprises the following steps: each consensus node generates n secret shares, reserves one share, 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 own secret share and broadcasts the public verification parameter through an on-link contract; the contract adds the number of the node requesting broadcasting to the first node set; each consensus node verifies each secret share and the corresponding public verification parameter, and sends the node number failing to verify to the contract through complaint transaction; the contract determines a second node set according to the node numbers and the first node set of verification failure sent by all the consensus nodes; each consensus node calculates a public key share based on the verification parameter and the second node set, and calculates a private key share corresponding to the consensus node based on the local secret share and the second node set.

Description

Method and system for realizing retransmission of secret share and determining failure node on block chain

Technical Field

The embodiment of the specification belongs to the technical field of blockchains, and particularly relates to a method and a system for realizing distributed key generation on a blockchain.

Background

Blockchain (Blockchain) is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanisms, encryption algorithms, and the like. In the block chain system, the data blocks are combined into a chain data structure in a sequential connection mode according to the time sequence, and the distributed account book which is not tamperable and counterfeit and is ensured in a cryptographic mode is formed. Because the blockchain has the characteristics of decentralization, non-tamperability of information, autonomy and the like, the blockchain is also receiving more and more attention and application.

Disclosure of Invention

The present disclosure is directed to a method and system for implementing distributed key generation on a blockchain, including:

A method for realizing retransmission secret share in the distributed secret key generation process on a block chain, wherein each consensus node should generate n secret shares and corresponding public verification parameters, after receiving a signal for starting timing, one secret share should be reserved by itself, other n-1 secret shares should be respectively sent to other n-1 nodes in an encryption manner, and the public verification parameters corresponding to the secret shares should be broadcasted through an on-chain contract; the contract should add the number of the node requesting broadcasting to the first node set;

if the first consensus node does not receive the secret share sent by the second consensus node within a first timeout period:

The first consensus node sends the number of the second consensus node to the contract by retransmitting the secret share request transaction and broadcasting by the contract;

And after receiving the broadcasted request for retransmitting the secret share, the second consensus node transmits the secret share to the contract through a transaction for retransmitting the secret share.

The node is marked as a node that failed verification.

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

Each consensus node generates n secret shares and corresponding public verification parameters, after receiving a signal for starting timing, the consensus node reserves one share, and respectively encrypts and sends the n-1 secret shares to other n-1 nodes, and broadcasts the corresponding public verification parameters through on-link contracts; the contract adds the number of the node requesting broadcasting to the first node set;

A system for implementing a determination failure node in a distributed key generation process on a blockchain, comprising a plurality of consensus nodes, wherein:

Each consensus node should generate n secret shares and corresponding public verification parameters, after receiving a signal for starting timing, should itself reserve one secret share, should respectively encrypt and send other n-1 secret shares to other n-1 nodes, and should broadcast the public verification parameters corresponding to the secret shares through on-link contracts; the contract should add the number of the node requesting broadcasting to the first node set;

any of the consensus nodes sends the number of the second consensus node to the contract by retransmitting a secret share request transaction if the secret share of the second consensus node is not received within the first timeout time;

The contract receives at least f+1 re-transmission secret share request transactions for the same node within a second timeout period, and marks the node as a node with failed verification.

According to the scheme provided by the specification, on the basis that the integral consistency and synchronization of the blockchain network are guaranteed by a consensus mechanism, the distributed key generation is realized by combining the blockchain intelligent contracts, so that the generation of the distributed key is guaranteed to be generated by each participant through cooperation on one hand, and on the other hand, the generated result is consistent and reliable, the strong dependence of the generation of the distributed key on the network synchronization is avoided outside the original blockchain, and the problem of unreliability of the generated result under the condition is solved. And the second node can prevent the first node from misreporting that the retransmitted secret share is not received by retransmitting the secret share to the contract by trading the retransmitted secret share, thereby preventing such disfigurement.

Drawings

FIG. 1 is a schematic diagram of a conventional stage of a practical Bayesian fault tolerance algorithm in one embodiment;

FIG. 2 is a schematic diagram of a view switching phase of a practical Bayesian fault-tolerant algorithm in accordance with an embodiment;

FIG. 3 is a schematic diagram of a conventional phase of a practical Bayesian fault-tolerant algorithm with no downtime for the identified nodes in one embodiment;

FIG. 4 is a flow chart of generating random number seeds on a block chain in one embodiment of the present disclosure;

FIG. 5 is a schematic diagram of a block header structure in one embodiment of the present disclosure;

FIG. 6 is a flow chart of generating random number seeds on a block chain in one embodiment of the present disclosure;

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

Detailed Description

In order to make the technical solutions in the present specification better understood by those skilled in the art, 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 some embodiments of the present specification, not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are intended to be within the scope of the present disclosure.

The blockchain 1.0 age is generally referred to as the blockchain application development phase between 2009 and 2014, which is mainly aimed at solving the problem of decentralization of currency and payment means. Since 2014, developers are increasingly focusing on solving the technical and extensibility deficiencies of the aforementioned approaches. At the end of 2013, vitalik Buterin introduced intelligent contracts into the blockchain, opening applications of the blockchain outside the currency domain, and thus opening the blockchain 2.0 era.

In a blockchain system, different participants can establish a distributed blockchain network through deployed nodes (nodes). The decentralized (or multicentric) distributed ledger constructed using the chain block structure is stored on each node (or on a large number of nodes, such as consensus nodes) in the distributed blockchain network. Such blockchain systems need to address the problem of consistency and correctness of ledger data on each of a plurality of nodes that are de-centralized (or multicentric). Each node (or a plurality of nodes) runs a blockchain program, and under the design of certain fault tolerance requirements, all the loyalty nodes are guaranteed to have the same transaction through a consensus (consensus) mechanism, so that the consistency of the execution results of all the loyalty nodes on the same transaction is guaranteed, and the transaction and the execution results are packed to generate a block.

An intelligent contract is a computer contract that is automatically executable based on prescribed triggering rules and can also be considered a digital version of a traditional contract. The concept of smart contracts was first proposed by cross-domain law scholars, cryptology researchers, nike-sabo (nickel Szabo) in 1994. This technology has not been used in the real industry for a short time because of the lack of programmable digital systems and related technologies until the advent of blockchain technology has provided a reliable execution environment for it. Because the blockchain technology adopts the blockchain ledger, the generated data cannot be tampered or deleted, and the whole ledger can be continuously added with ledger data, thereby ensuring the traceability of historical data; meanwhile, the operation mechanism of decentralization avoids the influence of the decentralization factor. The intelligent contract based on the block chain technology not only can exert the advantages of intelligent combination in terms of cost and efficiency, but also can avoid the interference of malicious behaviors on the normal execution of the combination. The intelligent contracts are written into the blockchain in a digital mode, and the transparent trackable and tamper-proof processes of storage, reading and execution are guaranteed by the characteristics of the blockchain technology.

Blockchain development and application diversity. Some business logic is compiled as intelligent contracts and executed on a blockchain platform. In particular, these intelligent contracts containing business logic may run on each node (or on a large number of nodes, such as consensus nodes) in the blockchain network. The execution of the intelligent contracts in a blockchain environment is also referred to as "world computers" as opposed to the problem of a centralized business logic execution environment resulting from a single point of failure that results in the entire centralized system being unavailable, because there are many nodes in the distributed blockchain network that each independently execute the intelligent contracts. As previously mentioned, intelligent contracts executing the same logic on these different nodes require the same execution results to be obtained, thereby ensuring that most of the stored ledgers in these nodes are consistent.

In some business logic, it may be necessary to generate a result based on a random number, for example, to implement business logic for lottery, to implement business logic for shaking numbers, or to implement business logic for random amount of money for red-out, blind-box, etc., which generally requires a program for generating a random number to be included in the smart contract. As another example, in some system contracts, it may be desirable to implement voting on the master node or voting on a small-scale committee, and this voting logic may be in a random fashion or using a random number. As previously mentioned, there is a significant feature in distributed blockchain networks in that it is necessary for the account books in the majority of nodes to be consistent in order to ensure that the distributed blockchain network is entirely available, which also requires that the random numbers generated by the smart contracts in the majority of nodes be consistent.

In the foregoing description, each node (or a plurality of nodes) runs a blockchain program, and under the design of a certain fault tolerance requirement, all the loyalty nodes are guaranteed to have the same transaction through a consensus mechanism, so that the consistency of the execution results of all the loyalty nodes on the same transaction is guaranteed, and the transaction and the execution results are packed to generate a block. The consensus mechanisms of the current mainstream include: proof of Work (POW), proof of equity (POS), proof of commission (DELEGATED PROOF OF STAKE, DPOS), practical bayer fault tolerance (PRACTICAL BYZANTINE FAULT TOLERANCE, PBFT) algorithms, melder bayer fault tolerance (HoneyBadgerBFT) algorithms, and the like.

Taking PBFT as an example, the algorithm is proposed by Miguel Castro and Barbara Liskov (liskov) in 1999, the problem that the original bayer fault-tolerant algorithm is not efficient is solved, and the algorithm complexity is reduced from an exponential level to a polynomial level, so that the bayer fault-tolerant algorithm becomes feasible in practical system application. The paper was published in 1999 on the operating system design and implementation international conference (OSDI 99). In PBFT algorithm, all copies (replicas) run in a rotation process (succession of configuration), called View. In one view, one copy acts as a primary node (primary) and the other copies act as backup nodes (backups). Views are integers numbered consecutively. The master node may be calculated from 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. It is assumed in this algorithm that when there are at most f copies (i.e., nodes) to fail, if there are at least 3f+1 copies in total, it is guaranteed that security and activity are provided in an asynchronous system. The set of a certain number of copies needed to be able to ensure data consistency requirements and fault tolerance requirements of all copies is typically the set of most nodes in the distributed system, constituting the majority (Quorum). For example, if the total node number n is 3f+1 (n=3f+2 or n=3f does not generally increase the fault tolerance effect), the number of quum is 2f+1. Thus, for a distributed system comprising four nodes, any three nodes may constitute a Quorum.

PBFT includes both Normal CASE PHASE and VIEW CHANGE PHASE processes, and FIG. 1 is a flow chart of the Normal CASE PHASE (conventional phase) process. The Normal CASE PHASE mainly includes three stages of PRE-preparation, and COMMIT, wherein node No. 3 may represent, for example, a downed node (represented by x in fig. 1). When the Primary node fails (denoted by x in fig. 2), the view replacement (VIEW CHANGE) process needs to be started if the Primary node Primary (duplicate 0) fails before the view is replaced, so that adjustment is performed when the system fails, and a new Primary node is replaced (e.g., the Primary node Primary is Replica 1 after the view is replaced). Fig. 2 is a schematic diagram of VIEW CHANGE PHASE (view switching). The client may set a timeout mechanism if the master node drops or does not broadcast the client's request, etc. If timed out, the client may broadcast a request message to all duplicate nodes. After the duplicate node detects that the master node is bad or down, a VIEW CHANGE protocol phase may also be initiated to replace the master node (often referred to simply as "change master"). In addition, the PRE-PREPARE, PREPARE and COMMIT three-phase consensus process may fail due to the main node initiating the wrong proposal, or PREPARE, COMMIT phases may not be consistent with the number of Quorum (such as 2f+1 of 3f+1 nodes, also called Quorum), and the consensus cannot be completed. It is also possible in these cases to initiate VIEW CHANGE a protocol phase to replace the master node.

Under Normal conditions, i.e. no failure of the consensus nodes, the consensus messages can reach each other within a certain time, i.e. no change of masters occurs, the Normal CASE PHASE process in PBFT can be shown in fig. 3, which still takes 4 consensus nodes as an example.

After the Normal CASE PHASE process of round r-1, node 0 is used as a master node to collect a certain number of transactions to be agreed (or a read-write set, etc., and the following is exemplified by transactions), a PRE-preparation process (i.e. the aforementioned PRE-preparation, also referred to as PP phase) is initiated, and then nodes 1, 2, 3 enter into a preparation process (i.e. the aforementioned preparation, also referred to as P phase), and then nodes 0, 1, 2, 3 enter into a COMMIT process (i.e. the aforementioned COMMIT, also referred to as C phase). PP-, P-, C-phases are also commonly collectively referred to as PBFT three phases. Thus, the three-stage process of the r-1 th wheel PBFT is normally completed, the consensus of the transaction data corresponding to the m-1 th block is completed, and the information such as the block number of the block is also generated. Thus, each consensus node can execute the transactions in the order and content of the consensus transaction data based on the consensus transaction data, thereby generating a world state and receipt. Specifically, each node can construct a Merkle tree (including a tree structure such as an MPT tree, which is collectively referred to as MERKLE PATRICIA TREE, which is a tree structure combining MERKLE TREE (merck tree) and PATRICIA TREE (compressed prefix tree, a more space-saving Trie, dictionary tree) based on the commonly recognized transaction data and generate a hash of the tree root of the Merkle tree (also referred to as a transaction root hash), and similarly, can construct a Merkle tree based on the world state data and generate a hash of the tree root of the Merkle tree (also referred to as a state root hash), and can construct a Merkle tree based on the receipt data and generate a hash of the tree root of the Merkle tree (also referred to as a receipt root hash). After each node generates the three root hashes locally, each node can generate the m-1 block locally. The block header of the m-1 th block may include the aforementioned block number, transaction root hash, status root hash, receipt root hash, etc., and the block may include a transaction data set, a world status set, and a receipt set. Thus, the m-1 th block is generated.

In the generation of the mth block, the three-stage process in PBFT will be repeated. As shown in fig. 3, for the mth block, after a certain number of transactions to be identified are collected by the node 0 as a master node, a PP process is initiated, and then nodes 1,2 and 3 enter a P process, and then nodes 0, 1,2 and 3 enter a C process. Thus, the three-stage process of the r-th wheel PBFT is normally completed, that is, the consensus of the transaction data corresponding to the mth block is completed, and the information such as the block number of the block is generated. Each node may execute the transactions in the order and content of the consensus transaction data based on the consensus transaction data, thereby generating a world state and receipt. Each node may locally generate the mth chunk after generating three root hashes as described above. The block header of the mth block may include the aforementioned block number, transaction root hash, status root hash, receipt root hash, etc., 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+1th block is generated, which includes a three-stage process of the r+1th wheel PBFT as shown in fig. 3.

It can be seen that in the case of conventional generation of blocks, each common node includes a Normal CASE PHASE process of PBFT once in the generation of each block. As the blocks continue to be generated, each consensus node repeats this consensus process, with the r-1, r, and r+1 round consensus processes being shown only by way of example in FIG. 3. Wherein, some of the consensus nodes are in the role of master nodes in PBFT and some of the consensus nodes are in the role of backup nodes in PBFT.

During a consensus process, i.e., during three phases of one PBFT, may include:

a110: after collecting a certain number of transactions to be agreed, the master node 0 orders and packages the transactions to be agreed into a message m (also called an original transaction list), and sends a PRE-preparation request to the backup nodes 1,2 and 3, wherein the PRE-preparation request comprises the original transaction list;

a120: after receiving the pre-preparation request, the nodes 1,2, 3 (preparation stage) broadcast the hash value of the message m received by them via the preparation message, respectively, 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, and the volume is generally relatively large). Specifically, node 1 diffuses the preparation message to nodes 0, 2,3, node 2 diffuses the preparation message to nodes 0, 1, 3, and node 3 diffuses the preparation message to nodes 0, 1, 2. Correspondingly, each node also receives the preparation message broadcast by other nodes. Each node adds both its own transmitted preparation message (which contains the hash value of message m, representing its own approval) and the received preparation message (which contains the hash value of message m, representing the approval of the other nodes) to the local Log (Log). If a node gathers at least a number of legitimate pp messages/p messages from different nodes (including its own sent pre-prepare, prepare message, and received preparation message), it transitions to prepared state.

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

A140: the node transitioning to the committed state outputs message m as a consensus result for the round.

Which transactions are contained in message m, and the order of the contained transactions, are generally determined by the master node in a 110. It is determined which transactions are involved, in which order the involved transactions are in front of and behind, both of which are important contents of the consensus mechanism. Many transaction requests may be received in the blockchain network, and the master node in a110 packages which transactions, decides which transactions will be processed by the blockchain network, and the execution result of the transactions will be uplink. Even with a set of identical transactions, differing order of execution from front to back may result in differing end results, which affects whether the ledgers at the various 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 PBFT three-stage process. As shown in fig. 4, includes:

S110: in the commit phase of PBFT, each consensus node signs the original message containing the unique value of the original transaction list in the current consensus by using its own private key share based on a threshold signature algorithm, generates a signature share, and adds the signature share to the broadcasted 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 by Ronand Livister (Ron Rivest), addisor (ADI SHAMIR), and Leonard Adleman (Lenard Adleman) together in 1977. The RSA algorithm can finish decryption without directly transmitting the key, so that the security of the information can be ensured, and the risk of cracking the information caused by directly transmitting the key is avoided. RSA includes a private key and a public key, which are paired. After one message is encrypted by the public key, the message can only be decrypted by the corresponding private key; similarly, after an information is encrypted by a private key, it can only be decrypted by the corresponding public key. This is so because the pair of private and public keys has a mathematical correlation, for example, one underlying principle is that it is relatively simple to find two large primes according to theory of numbers, and it is extremely difficult to factorize their products, so that the products can be disclosed as encryption keys, and security can be ensured. The private key is usually kept secret and cannot be revealed, while the public key is public (and can be held by multiple persons). Because the private key is kept secret by the holder, others cannot forge the signature of the holder of the private key without obtaining the private key.

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

b1: a generates a pair of keys (public and private), the private key is not public and is reserved by itself. The public key is public and available to anyone.

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

The hash algorithm is also called a hash algorithm, and can map the original content into a fixed-length sequence, which is a hash value. There are typically sha256, sha384, sha512, etc. hash algorithms. The result of sha256 is 256 bits, which can represent 256 original contents to the power of 2. Similarly, the result of sha384 is 384bits, and the result of sha512 is 512bits. These hash algorithms can be directed to original content that is more voluminous and larger in content, and thus the hash value can be relatively much smaller than the original content. The good hash algorithm can ensure that different original contents have a great probability of being mapped into different hash values, and meanwhile, the mapping is disordered, namely the relevance of the hash values obtained by the different original contents cannot be predicted; and the method is also anti-reverse operation, namely the original content cannot be obtained by reverse pushing of the hash value.

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

B3: and B, after receiving the message, adopting the public key of A to carry out signature verification.

On the one hand, the hash value of the original message can be calculated by adopting the same hash algorithm as that of the A, and is calculated as hash1; and on the other hand, B adopts the public key of A to decrypt and calculate the signature result to obtain hash2. If hash1 is the same as hash2, it can be determined that the received original message is sent by a and has not been tampered with during the transmission process.

The threshold signature scheme first includes 1 total public key and n public-private key pairs. 1 public key of each public-private key pair is called a public key share, and 1 private key of each public-private key pair is called a private key share. Second, there is a recovery function corresponding to the pair of the total public key and the n public-private keys, which can recover the signature shares of at least a threshold number of the different private key share signatures into a complete signature, which can also be verified by said 1 total public key. Any less than a threshold number of signature shares may not be able to resume generating the complete signature.

In addition to the RSA-based threshold signature mechanism, an ECDSA ((Elliptic Curve Digital Signature Algorithm, elliptic curve digital signature algorithm)) based threshold signature mechanism, a Schnorr (a discrete logarithm problem-based knowledge proof mechanism), a BLS (Boneh-Lynn-Shacham Signature) based threshold signature mechanism, etc. may be employed.

It should be noted that the number of private key shares may be equal to the number of consensus nodes for the threshold signature employed in the blockchain, and the number of minimum signature shares (i.e., the threshold number) that the recovery function generates the complete signature may be equal to quorum in the PBFT algorithm. Of course, the number of private keys may not be equal to the number of consensus nodes, and the number of minimum signature shares generated by the recovery function to produce 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 blockchain consensus nodes, which belongs to a centralized key distribution mode. Thus, in conjunction with the consensus algorithm, n private key shares may be one held by each blockchain consensus node. At the same time, each blockchain consensus node may hold the same 1 total public key. In addition, there is a decentralised key allocation manner, that is, dealer is cancelled, but the n public-private key pairs and 1 total public key are obtained by negotiation of the n consensus nodes through the key negotiation process, and each consensus node still holds one of the n private key shares independently, and each consensus node holds the same total public key.

By adopting the threshold signature algorithm, each consensus node can sign the original message containing the unique value of the original transaction list in the current consensus by adopting the own unique private key (for example, in a blockchain network containing 4 nodes and adopting PBFT as the consensus algorithm, the private key shares held by the threshold signature algorithm by the node 0, the node 1, the node 2 and the node 3 are sk ₀,sk₁,sk₂,sk₃ respectively, and the subscript number can represent the number of the node), so as 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 contents of transactions are different from transaction to transaction, and thus, the different original transaction lists or their hash values are generally different. Therefore, the original message may at least include the original transaction list or the hash value thereof, so that the nature of the hash function is sufficient to distinguish the random number seeds generated after the corresponding consensus process of the different blocks is completed.

Considering that a number is generated for the content of the current consensus in the consensus process, if the consensus is completed, the generated number can be used as the block number of the block corresponding to the current consensus, so the block number (i.e. the number) can also be used as the content in the original message. Whether or not the original transaction list contained in the n+1th block is identical to the original transaction list contained in the N-th block, the block generation is sequential, and it may be embodied that the block number of the subsequent 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+1th block is the same as the original transaction list contained in the n+1th block, each node still obtains different signatures based on the (original transaction list+block number) by adopting the private key of the node, and the master node still cannot know the signatures of other nodes, so that the complete signature of the n+1th block cannot be predicted, and therefore, the master node cannot use the random number seed disclosed by the n+1th block to predict the random number seed of the n+1th block, thereby achieving the unpredictable aim. Like numbered, the timestamp is also unique to one block, and the timestamp of the following block follows the preceding block. Thus, the timestamp may also be the content in the original message.

In addition to the unique value of the original transaction list, the signed object may be added to other content, such as the random number seed generated in the previous block, i.e. the original message may also include the random number seed generated in the previous block. After the above-mentioned execution of a140, each node may generate the mth block based on the consensus transaction data, as described above. Since the mth chunk is generated by each node independently locally, if the hash value of the last chunk generated by each node is not broadcast and compared with each other between the blockchain nodes, each node may not be able to determine whether the mth chunk generated in the blockchain network is the same, or whether the mth chunk generated on at least quorum common nodes is the same from the standpoint of the availability of the blockchain system as a whole. Through the random number seed generation process 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, the complete signature may not be obtained through the recovery function in the process of generating the random number seeds of the mth+1th block according to the nature of the threshold signature algorithm, so that the consensus node can be helped to confirm whether the previous block is consistent according to the scheme of the specification. The hash value of the previous block can also be used to replace the random number seed of the previous block, and the common node can also be helped to confirm whether the previous block is consistent or not because the hash value of the previous block is generally unique.

The original message containing the unique value of the original transaction list in the common knowledge is signed by adopting the share of the private key, and the unique value of the original transaction list which can be included in the original message can be the original transaction list. The original transaction list has been generally broadcast in PP stage PBFT, and smaller commit messages broadcast in C stage are more beneficial to spread and save bandwidth, so the original transaction list unique value may be the hash value of the original transaction list.

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

The original message is signed, and the generated signature result and the original message can be added into the broadcast commit message together. Thus, in the commit phase, each of the nodes participating in the consensus transmits a commit message to the other consensus nodes and adds its own sent commit message to the local Log (representing its own approval), and each node also receives commit messages broadcast by the other nodes.

S120: after each consensus node collects at least a threshold number of commit messages, the authenticated at least threshold number of signature shares are subjected to a recovery function corresponding to a private key share generated by the threshold signature algorithm to obtain a complete signature.

As previously described, the threshold signature algorithm may generate 1 total public key and n public-private key pairs in pairs and may generate a recovery function corresponding to the n public-private key pairs in an application. 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, i.e., the threshold number, of the threshold signature algorithm may be set to w. Of course, a complete signature can also be generated by the recovery function when there are more than w correct signatures. That is, when the number of correct signatures is equal to or greater than the threshold number w, a complete signature can be generated by the recovery function, and the generated complete signature is determined and does not change due to the number of correct signatures (as long as the number is equal to or greater than w).

This generated complete signature can be verified for correctness by the 1 total public keys. In this way, any node holding this total public key can use the total public key to verify the correctness of this 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 total public key is used to perform cryptographic operation on the complete signature to obtain a first hash, and perform hash operation on the original message 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 that 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 message may be sent to a device other than the blockchain, where the device may use the total public key and the original message to verify the correctness of the complete signature, and the principle is not described in detail. The message is still the content containing the unique value of the original transaction list in the current consensus, or further comprises the block number and/or the time stamp of the current block and/or the random number seed generated in the previous block.

In addition, after each consensus node collects each commit message, the corresponding public key share is adopted to verify the signature share in the received commit message, and then the at least threshold number of signature shares are subjected to a recovery function corresponding to the private key share generated by the threshold signature algorithm to obtain a complete signature. Compared with the 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 share and recovering the complete signature through the recovery function after verification is passed can determine which signature is wrong, so that which node is likely to be a bad node can be determined.

In the threshold signature algorithm, each consensus node has 1 private key share and 1 public key share in 1 total public key and n public private key pairs, and as described above, the public key shares and the 1 public key shares can be generated and distributed by dealer or negotiated by 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 PBFT consensus algorithm containing 4 consensus nodes, node 0 broadcasts its own generated signature share σ _3,0 to nodes 1,2,3 in S110, where subscript 3 of σ _3,0 may represent the block number, and 0 may represent that this is the signature share of node 0; in S120, node 0 also receives signature shares σ _3,1、σ_3,2 broadcast by nodes 1,2, respectively. Thus, node 0 has already collected at least 3 signature shares, including self-broadcast signature share σ _3,0 and node 1,2 broadcast signature share σ _3,1、σ_3,2. Of course, node 0 may also collect all signature shares σ _3,0、σ_3,1、σ_3,2 and σ _3,3, which of course also satisfies at least the quorum number.

Further, node 0 may verify the correctness of the collected σ _3,0、σ_3,1、σ_3,2 or further comprising σ _3,3 (or σ _3,0、σ_3,1、σ_3,3 or further comprising σ _3,2, or σ _3,1、σ_3,2、σ_3,3 or further comprising σ _3,0, or σ _3,0、σ_3,2、σ_3,3 or further comprising σ _3,1) with the corresponding public key share. Specifically, for example, node 0 may calculate the signature share σ _3,1 using the corresponding public key share to obtain a hash value, denoted as hash _3,1; node 0 may also perform the same hash calculation on the original message to obtain hash' _3,1. If hash _3,1 is equal to hash' _3,1, it can be verified that the original message was sent by node 1 and has not been tampered with during the transmission. In this way, the correctness of σ _3,1 is verified. Similarly, node 0 may verify σ _3,2, etc., and will not be described in detail.

Likewise, node 1 may verify the correctness of the collected σ _3,0、σ_3,1、σ_3,2 or further comprising σ _3,3 (or σ _3,0、σ_3,1、σ_3,3 or further comprising σ _3,2, or σ _3,1、σ_3,2、σ_3,3 or further comprising σ _3,0, or σ _3,0、σ_3,2、σ_3,3 or further comprising σ _3,1) with the corresponding public key share.

Likewise, node 2 may verify the correctness of the collected σ _3,0、σ_3,1、σ_3,2 or further comprising σ _3,3 (or σ _3,0、σ_3,1、σ_3,3 or further comprising σ _3,2, or σ _3,1、σ_3,2、σ_3,3 or further comprising σ _3,0, or σ _3,0、σ_3,2、σ_3,3 or further comprising σ _3,1) with the corresponding public key share.

Likewise, node 3 may verify the correctness of the collected σ _3,0、σ_3,1、σ_3,2 or further comprising σ _3,3 (or σ _3,0、σ_3,1、σ_3,3 or further comprising σ _3,2, or σ _3,1、σ_3,2、σ_3,3 or further comprising σ _3,0, or σ _3,0、σ_3,2、σ_3,3 or further comprising σ _3,1) with the corresponding public key share.

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

A random seed (random seed) refers to an 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 may be obtained starting from the same random number seed. For a stand-alone, the random number seed may be determined by the state of the current computer, such as the current time. For a distributed system, the same random number seed is generated on each node, so as to generate the same random number based on the same random number seed in a system contract/business contract/blockchain platform function and the like, and no node should generate the random number in a controllable, predictable and revocable manner. 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 instant point of view, it is also necessary to generate and use a random number when the transaction in the current block is executed.

Through the steps of S110-S120, each consensus node can obtain the same complete signature under normal conditions. Of course, in view of the fault tolerance characteristics of the distributed system, at least quorum number of consensus nodes in the blockchain network using PBFT consensus algorithm can each obtain the same complete signature.

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

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

Thus, the blockchain node may execute based on the random number seed of S130 if it contains the smart contract/system contract/blockchain platform code that requires the use of random numbers in the course of outputting the consensus result after the current consensus is performed, i.e., in the course of performing a series of transactions that determine the content and order. For example, in an intelligent contract written in the c++ language, an mt19937 (r) method provided by a c++ standard library or a boost library may be used to construct a cross-platform consistent random number engine, where the parameter r is a random number seed. Similarly, the random library in python, the random library in java, all provide similar methods of random number generation. Based on the same random number seed, the same random number may be generated under the same random number generation algorithm. Thus, for example, when each block link point performs the same transaction in the same block, the same random number can be generated based on the same random number seed for the same random number generation process, thereby completing business logic such as shaking numbers, reddening packets, blind boxes, or completing system contract/block chain platform functions, and obtaining consistent execution results on each node.

In addition, on the basis of the scheme, the method further comprises the following steps of:

S140: each consensus node places the resulting random number seed into 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 a previous_hash (Prev Hash in the figure), nonce (which is a random number involved in the proof of workload, unlike the random number seed in the present specification, and this Nonce is not enabled in some federation chains), timestamp, previous Block number, state Root Hash Root, transaction Root Hash Root, receipt Root Hash Receipt Root, and so on. The Prev Hash in the block 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 block 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 included in the block header is sequentially spliced. In this way, the lock of the next block to the previous block is achieved by the block header on the blockchain. In particular, as described above, the state root is a hash value of the root of the MPT tree consisting of the states of all accounts in the current block, and points to state_root's state tree STATE TRIE in the form of one MPT. The Transaction Root is generally a hash value of a tree Root node of an original Transaction list included in the block and organized into a tree structure, and Receipt Root is generally a hash value of a tree Root node of all receipts generated after the Transaction included in the block is executed and organized into a tree structure.

It should be noted here that this specification may add a field "random number seed" to 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 blockchain ledger, and furthermore, for the playback block, the transaction involving the random number in the block can be played back according to the random number seed in the block header.

According to the scheme provided by the 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 through the PBFT algorithm, the complete signature can be obtained through the adopted threshold signature algorithm, thus a random number seed is obtained, and the random number can be adopted in the process of executing the transaction in the original transaction list corresponding to the block, so that no additional waiting is needed for executing the transaction of the block.

According to the scheme provided by the specification, based on the nature of the threshold signature algorithm, each consensus node can recover the same complete signature through a recovery function based on at least a threshold number of signature shares respectively, and then the same random number seeds are generated, so that when each block chain node respectively executes the same transaction in the same block, the same random number generation process can generate the same random number based on the same random number seeds, thereby completing business logic such as a shaking number, a reddish bag and a blind box, or completing system contract/block chain platform functions, and obtaining consistent execution results on each node.

According to the scheme provided by the specification, the threshold signature algorithm is combined with the PBFT consensus algorithm, so that the complete signature cannot be predicted by any consensus node before the consensus is completed, and the complete signature cannot be predicted even by the master node of PBFT, and the random number seed and the random number cannot be predicted. In particular, when the threshold= quorum, once the consensus is completed, since the content and the sequence of the transaction list are agreed by quorum number of nodes, that is, the basic content of the generation of the new block is determined, at least quorum number of nodes obtain the same complete signature according to the recovery function, the random number seed generated by quorum number of nodes is also necessarily the same, and even if there are no more than f nodes that are disliked and want to control or cancel the obtained random number seed, the f nodes will not affect the consistency of the system, that is, the f nodes cannot manipulate or cancel the generated complete signature, the random number seed and the random number.

The method in this specification may be implemented during the generation of each block, so that the block header of each block may include a field of a random number seed. Even if the block of a block does not contain a transaction involving a random number, the generation of the block may still include the generation of a random number seed.

In the following blockchain network that performs transactions in the consensus transaction list after the prior consensus transaction list, a method for generating a random number seed on a blockchain in the present specification is described in terms of a consensus node in the blockchain network, and the consensus algorithm is adopted to output a consensus result by broadcasting a commit proposal in the last stage, 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 the unique value of the original transaction list in the current consensus by adopting a private key share based on a threshold signature algorithm, generates a signature share, and adds the signature share into the broadcasted consensus message.

In addition to PBFT outputting consensus results by broadcasting the commit proposal to each other in the last phase, some consensus algorithms may also output consensus results by broadcasting the commit proposal to each other in the last phase, such as chinese patent ZL202111175184.1、ZL202111178795.1、ZL202111178745.3、ZL202111178754.2、ZL202111175144.7、ZL202111175151.7 and chinese patent application CN202111178779.2.

By adopting a threshold signature algorithm, the consensus node can sign the original message containing the unique value of the original transaction list in the consensus by adopting the unique private key share of the consensus node, and a signature result is obtained. 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. The block number (i.e., number) and/or timestamp may also be used as the content in the original message. In addition to the unique value of the original transaction list, the signed object may be added with other contents, such as a random number seed generated in the previous block, i.e. the original list may also include a random number seed generated in the previous block, so that the consensus node may be assisted in confirming whether the previous block is consistent according to the scheme of the present specification.

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

As described above, the threshold signature algorithm may generate 1 total public key and n public-private key pairs in the application, and may generate a recovery function corresponding to the n public-private key pairs. 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 to w. Of course, a complete signature can also be generated by the recovery function when there are more than w correct signatures. That is, when the number of correct signatures is equal to or greater than the threshold number w, a complete signature can be generated by the recovery function, and the generated complete signature is determined and does not change due to the number of correct signatures (as long as the number is equal to or greater than w).

This generated complete signature can be verified for correctness by the 1 total public keys. 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 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 total public key is used to perform cryptographic operation on the complete signature to obtain a first hash, and perform hash operation on the original message 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 that 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 message may be sent to a device other than the blockchain, where the device may use the total public key and the original message to verify the correctness of the complete signature, and the principle is not described in detail. The message is still the content containing the unique value of the original transaction list in the current consensus, or further comprises the block number and/or the time stamp of the current block and/or the random number seed generated in the previous block.

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 PBFT consensus algorithm containing 4 consensus nodes, node 0 broadcasts itself generated signature shares σ _3,0 to nodes 1,2, 3 in S210, where subscript 3 of σ _3,0 may represent the block number, and 0 may represent that this is the signature share of node 0; in S220, node 0 also receives the signature shares σ _3,1、σ_3,2 broadcast by nodes 1,2, respectively. Thus, node 0 has already collected at least 3 signature shares, including self-broadcast signature share σ _3,0 and node 1,2 broadcast signature share σ _3,1、σ_3,2. Of course, node 0 may also collect all signature shares σ _3,0、σ_3,1、σ_3,2 and σ _3,3, which of course also satisfies at least the quorum number.

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

Through the steps S210-S220, the consensus node can obtain a complete signature under normal conditions. In this way, the consensus node may employ a random number seed generation algorithm to generate a random number seed based on the full signature. A simpler random number seed generation algorithm is, for example, the sha256 algorithm. Of course, the complete signature may also be used directly as a random number seed.

Through the above process, a random number seed can be generated on the blockchain local to the consensus node.

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

The present disclosure further provides a method for generating a random number on a blockchain, which may further include, based on the S210-S230 method: the consensus node generates a random number based on the generated random number seed.

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, or the like. In the adopted threshold signature algorithm, 1 total public key and n public-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 consensus nodes, each holding one of the private keys, i.e. one private key share. Thus, each consensus node signs the original message with 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 generated by the corresponding recovery function as a certain complete signature, irrespective of at least which w of the n signature shares, as long as the at least w signatures are signatures made to the same original message with the respective correct private key shares.

In order to implement the threshold signature algorithm on the consensus nodes of the blockchain, a mechanism is needed to make n consensus nodes have 1 private key share and corresponding 1 public key share, respectively, and all have the same total public key. The foregoing may be generated by a centralized dealer and distributed to the n blockchain consensus nodes, which belongs to the centralized key distribution approach. This centralized key distribution requires the aid of a third party dealer, requiring that this dealer not be compromised. For example, implementation of a distributed key generation (Distributed Key Generation) protocol, in principle, requires the generation of a polynomial of degree t, then taking n points above the curve formed by the polynomial, generating n private key shares from the n points, and distributing the n private key shares to n threshold-signed participants. If the process is performed on one dealer, then if the dealer is bad, the dealer can obtain the private key shares of all n participants, which is not in compliance with the blockchain system security requirements.

In addition, there is a decentralised key generation and distribution mode, that is, dealer is cancelled, but instead, n public-private key pairs and 1 total public key are obtained by negotiation of n consensus nodes through a key negotiation process, each consensus node still holds one of n private key shares independently, and each consensus node holds the same total public key. In this manner, described above, it is conventional to implement outside of the blockchain and rely on network synchronization. Nodes on a blockchain are forming a distributed network, which is typically semi-synchronous or asynchronous. Thus, 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 an important precondition for generating random number seeds on the blockchain.

The aforementioned PBFT protocol belongs to the semi-synchronous (partial synchronous) protocol, which is characterized by the assumption that the network is initially asynchronous, but can start to synchronize from a certain moment. To let different nodes agree on the same proposal in the network, the simplest way is to set up a master node, which unifies the ideas of the various nodes. By setting the timer, master node errors can be prevented. PBFT, if Normal CASE PHASE is not completed within a limited time, backups is triggered to initiate VIEW CHANGE PHASE to replace the master node. PBFT to fix the master node in a position, all requests may be sent to the master node before being broadcast by the master node to other consensus nodes. In contrast, honeyBadgerBFT (also often referred to simply as HBBFT) algorithms belong to an asynchronous (asynchous) protocol. Asynchronous protocols are applicable to asynchronous networks, i.e. messages between nodes in the network can be arbitrarily delayed but eventually arrive. HoneyBadgerBFT removes the timer and drives the protocol execution by messages. Meanwhile, all nodes in HoneyBadgerBFT algorithm are peer-to-peer, and there is no division between the main node and the backup node, so there is no process of changing the main. HBBFT and other asynchronous network consensus protocols have no concept of master nodes, each node can propose requests and try to construct blocks, so that the asynchronous network protocol relieves the problems of fairness and single node bottlenecks to a certain extent.

For example, chinese patent ZL202111175184.1、ZL202111178795.1、ZL202111178745.3、ZL202111178754.2、ZL202111175144.7、ZL202111175151.7 and chinese patent application CN202111178779.2, both consider the characteristics of the semi-synchronous or asynchronous networks of the blockchain network and propose new consensus algorithms.

Through various consensus mechanisms in the blockchain network, the overall consistency and synchronization of the blockchain network can be ensured. For the latter, the synchronization of the blocks can be achieved as long as the blockchain can continue to output blocks. Then, it would be reliable to implement distributed key generation in conjunction with blockchain.

A method for implementing distributed key generation on a blockchain is described in the present specification with reference to fig. 7, including:

S310: each consensus node generates a unique set of n secret shares, itself retains one, and encrypts each of the n-1 secret shares for transmission to the other n-1 nodes.

The nodes are renumbered in the DKG algorithm, starting from 1. Here, in order to agree with the DKG algorithm, the consensus node is also numbered from 1.

Elliptic curve (El 1iptic Curve Cryptography, ECC) encryption algorithm is a public key encryption technique based on elliptic curve theory. The discrete logarithm difficulty of Abel (Abel) group formed by the points of elliptic curve on the finite field is utilized to realize encryption, decryption and digital signature. The elliptic curve will be described below as an example. Each node may randomly select a t-degree polynomial on the group Z _q. The polynomial function of degree N is uniquely determined by n+1 points, since it is ultimately required that quorum consensus nodes in the blockchain network can recover the signature, quorum =n+1, and therefore the degree t of the polynomial is quorum-1. In this way, recovery of a complete signature from quorum (quorum =t+1) signature shares via a recovery function can be achieved. Of course, t may be set to other values. An elliptic curve constructed with this polynomial can be expressed as follows:

f _i(z)＝a_i0+a_i1z+a_i2z²+…+a_itz^t formula (1)

In equation (1), a _i0,a₁₁,a_i2,a_i3,…,a_it is a coefficient of a polynomial, and a polynomial can be determined by this set of coefficients.

When the number n of consensus nodes of the blockchain network is set to 4, t=2 in the case that quorum adopting an algorithm such as PBFT, HBBFT or the like is 3. At this time, this polynomial is:

f _i(z)＝a_i0+a_i1z+a_i2z² formula (2)

Node 1 may randomly select a set of numbers from a finite prime number domain as coefficients, i.e., as a ₁₀,a₁₁,a₁₂, then the resulting polynomial is: f ₁(z)＝a₁₀+a₁₁z+a₁₂z².

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

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

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

Each node may further determine a set of secret shares based on the determined polynomial. The secret share may 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 employed by each node, and the purpose of modulo q for f _i (j) is to limit the value of f _i (j) to a range of 0, q-1. For example:

The consensus node 1 generates 4 secret shares, respectively S₁₁＝f₁(1)mod q,S₁₂＝f₁(2)mod q,S₁₃＝f₁(3)mod q,S₁₄＝f₁(4)mod q. here 4 secret shares, 4 being the total number of consensus nodes. That is, if it is to be finally achieved to take any w out of n signature shares, one complete signature can be generated by the recovery function, where n secret shares need to be generated. The following is the same.

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

The consensus node 3 generates 4 secret shares, one each S₃₁＝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, one each S₄₁＝f₄(1)mod q,S₄₂＝f₄(2)mod q,S₄₃＝f₄(3)mod q,S₄₄＝f₄(4)mod q.

Further, each node may exchange other generated secret shares with other consensus nodes over the P2P network in addition to reserving one secret share. The method can be concretely as follows:

Consensus node 1 reserves S ₁₁, sends S ₁₂ to node 2, sends S ₁₃ to node 3, and sends S ₁₄ to node 4, which may be sent by a Peer-to-Peer (P2P) network component of the bottom layer in the blockchain network. The secret shares to be sent need to be kept secret, and the consensus node 1 may encrypt the secret shares to be sent with the public key of the receiver and send them to the receiver, or send them to the receiver through a secure connection such as TLS (Transport Layer Security, secure transport layer protocol).

Consensus node 2 reserves S ₂₂, sends S ₂₁ to node 1, sends S ₂₃ to node 3, sends S ₂₄ to node 4, and can send through the underlying P2P network components in the blockchain network. Likewise, the transmitted secret shares need to be kept secret, and the consensus node 2 may encrypt the secret shares to be transmitted with the public key of the receiver and then transmit the secret shares to the receiver, or transmit the secret shares to the receiver through a secure connection such as TLS.

Consensus node 3 reserves S ₃₃, sends S ₃₁ to node 1, sends S ₃₂ to node 2, sends S ₃₄ to node 4, and can send through the underlying P2P network components in the blockchain network. Likewise, the transmitted secret shares need to be kept secret, and the consensus node 3 may encrypt the secret shares to be transmitted with the public key of the receiver and then transmit the secret shares to the receiver, or transmit the secret shares to the receiver through a secure connection such as TLS.

Consensus node 4 reserves S ₄₄, sends S ₄₁ to node 1, sends S ₄₂ to node 2, sends S ₄₃ to node 3, and can send through the underlying P2P network components in the blockchain network. Likewise, the secret shares to be sent need to be kept secret, and the consensus node 4 may encrypt the secret shares to be sent with the public key of the receiver and send them to the receiver, or send them to the receiver through a secure connection such as TLS.

Two digits in the subscript of the secret share are visible, the left hand number which may represent the node from which the secret share originates, and the right hand number which may represent the node from which the secret share is received. This is the case:

the consensus node 1 locally has a secret share S ₁₁、S₂₁、S₃₁、S₄₁ generated by a different node;

The consensus node 2 locally has a secret share S ₁₂、S₂₂、S₃₂、S₄₂ generated by a different node;

the consensus node 3 locally has a secret share S ₁₃、S₂₃、S₃₃、S₄₃ generated by a different node;

The consensus node 4 locally has a secret share S ₁₄、S₂₄、S₃₄、S₄₄ generated by a different node.

Wherein S ₁₁ local to the consensus node 1 is self-generated, S ₂₂ local to the consensus node 2 is self-generated, S ₃₃ local to the consensus node 3 is self-generated, and S ₄₄ local to the consensus node 4 is self-generated.

The consensus node preferably signs the secret share to be sent, for example with its own private key, or with MAC (Message Authentication Code ), so as to guarantee the 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 a public verification parameter corresponding to the secret share of the node and broadcasts the public verification parameter through an on-link contract; the on-link contract 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 the own key share, and the generation method can adopt the following formula:

In the formula (4), g is a base point on the elliptic curve. Depending on the operational nature of the elliptic curve, the power of g is also a point on the elliptic curve. t is the degree of the polynomial and is generally set to (quorum-1). As previously described, if it is to be finally achieved to take any w out of n signature shares, a complete signature can be generated by the recovery function, where the degree of the polynomial needs to be set to be t, where t=w-1. The following is the same.

Based on the above formula (4), let t=2, and the set of authentication parameters generated by the consensus node 1 be < a ₁₀,A₁₁,A₁₂ >, this set of authentication parameters is broadcast by the on-link contract. Similarly, based on the above formula, the consensus node 2 generates a set of verification parameters < a ₂₀,A₂₁,A₂₂ >, which are broadcast by the on-link contract. Similarly, based on the above formula, the consensus node 3 generates a set of verification parameters < a ₃₀,A₃₁,A₃₂ >, which are broadcast by the on-link contract. Similarly, based on the above formula, the consensus node 4 generates a set of verification parameters < a ₄₀,A₄₁,A₄₂ >, which are broadcast by the on-link contract.

Based on the cryptographic nature, a _ik publishes out, and a _ik is not pushed back, so even if published a _ik is obtained from the chain, the polynomial in S310 cannot be obtained.

Broadcast through the on-chain contracts, in particular, a transaction may be signed by each node with its own private key and sent to the blockchain. Each node may have a blockchain SDK built in (Software Development kit ). An SDK is a collection of program interfaces, documents, paradigms, development tools, etc. By having an SDK built in, the blockchain node may initiate transactions to the blockchain network like a blockchain client. The transaction issued by the blockchain node with its own private key signature may include a call to an intelligent contract on the blockchain. The invoked contract is, for example, a DKG contract. This DKG contract may be a system-level contract, i.e., a contract pre-deployed on the blockchain, e.g., a contract created from an account with system administrator rights, that serves as a system-level control function, rather than a contract developed and deployed by the user itself to implement some specific business logic.

Like other contracts, DKG contracts may be executed in a virtual machine (e.g., ethereum Virtual Machine, EVM), but may also be executed in a container (e.g., dock), as not limited herein. The external account initiates a transaction to the blockchain that invokes the on-chain contract, which may trigger execution of the contract. The contents of the transaction include, for example, from field, to field, value field, data field. The from field may be an account address of the transaction initiator, the to field may represent an address of the called smart contract, the value field may be a generic certificate native to the blockchain, and the data field may contain methods and parameters for calling the smart contract. By indicating the address of the smart contract called in the to field, a call to a certain smart contract on the blockchain may be indicated. One or more functions may be generally included in the smart contract, each of which may include some input parameters. The data field can be used for indicating a certain function in the intelligent contract to be called in the transaction, and parameters needing to be transmitted are filled in the data field.

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

Event：

[topic][msg]

......

In the above examples, the number of events may be one or more. Each event may include fields such as a theme (topic) and data (data). The format of the event output when the transaction is executed may be specified in the contract. Through the built-in SDK, the blockchain client or the blockchain node can monitor the event of the specific topic, pull the content of the corresponding msg under the condition of monitoring the event of the specific topic, 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 topic, so that a listener (namely a client or a blockchain node of the built-in blockchain SDK) listening to the topic can obtain the corresponding execution result. In S320, the public verification parameter that a node will generate may be transferred into the blockchain network by initiating a call to a first function (e.g., a function named Broadcast) in the DKG contract, where the function may include parameters that may include public verification parameters, and one result of the blockchain network executing the transaction is to place the public verification parameter into the msg corresponding to a specific topic in the receipt. So that the node listening to the topic can obtain the content in the msg field, i.e. obtain the public verification parameter. In this way, the on-link contract broadcasting is completed.

Events to snoop may be registered with the blockchain node through the SDK. Specifically, the blockchain node may bind a hook function to the generated event in the running blockchain platform code (the hook function may be compiled with the platform code during the development phase). This hook function belongs to a callback function that can be called when a listening event occurs and can execute certain processing logic. The snoop code may include, for example, one or more of snoop blockchain transactions, smart contracts, contract status, contract generated receipts, and the like. After registering a snoop event with the blockchain node through the SDK, the blockchain node may save a mapping relationship between the snoop event and a listener (e.g., a network connection of a client/node that puts the SDK and initiates event snooping, which may generally include information such as an IP address, a port number, etc.), e.g., a mapping relationship between a certain event snooping a certain contract and the listener. When the hook function monitors that the corresponding event theme (topic) occurs, the hook function can be called, and then the hook function can query the mapping relation and push the monitored event to the network connection. In this way, the SDK that initiates the snoop may obtain the snoop event over the maintained network connection. Execution of the contract is also broadcast by implementing the on-link contract in a similar manner. Specifically, the execution result of the contract and the execution result of other transactions in the block are stored in a transaction result buffer area of the blockchain node. When all transactions of the blockchain have been executed and organized into blocks, the blockchain platform code may snoop receipts in the transaction results, broadcasting the snoop events therefrom to the SDK that initiated the snoop. Here, through such a listening mechanism, a node may listen to a particular topic event registered and, when such an event occurs, obtain the msg corresponding to this topic through the maintained connection, thereby obtaining the content in the msg, where the content in the msg includes the public authentication parameter. In summary, broadcast public verification parameters can be implemented through event mechanisms of a blockchain, and broadcast content is received through an event listening mechanism.

Thus, the result of the common authentication parameters generated by broadcasting the nodes on the chain may be as follows:

The consensus node 1 locally has a secret share S ₁₁、S₂₁、S₃₁、S₄₁ generated by a different node and a verification parameter < a ₁₀,A₁₁,A₁₂ > and can obtain the common verification parameter from the chain <A₂₀,A₂₁,A₂₂>,<A₃₀,A₃₁,A₃₂>,<A₄₀,A₄₁,A₄₂>;

The consensus node 2 locally has a secret share S ₁₂、S₂₂、S₃₂、S₄₂ generated by a different node and the authentication parameter < a ₂₀,A₂₁,A₂₂ > and can obtain the common authentication parameter from the chain <A₁₀,A₁₁,A₁₂>,<A₃₀,A₃₁,A₃₂>,<A₄₀,A₄₁,A₄₂>;

The consensus node 3 locally has a secret share S ₁₃、S₂₃、S₃₃、S₄₃ generated by a different node and the authentication parameter < a ₃₀,A₃₁,A₃₂ > and can obtain the common authentication parameter from the chain <A₁₀,A₁₁,A₁₂>,<A₂₀,A₂₁,A₂₂>,<A₄₀,A₄₁,A₄₂>;

The consensus node 4 locally has a secret share S ₁₄、S₂₄、S₃₄、S₄₄ generated by a different node and the authentication parameter < a ₄₀,A₄₁,A₄₂ > and can obtain the common authentication parameter from the chain <A₁₀,A₁₁,A₁₂>,<A₂₀,A₂₁,A₂₂>,<A₃₀,A₃₁,A₃₂>.

As mentioned above, by broadcasting in the on-chain contracts, in particular, a transaction may be signed by each node with its own private key to be sent to the blockchain, for example, a node may send the generated public authentication parameter to the blockchain network by initiating a transaction, for example, invoking a function of Broadcast (r) in the DKG contract, where the function may include the parameter r, and r may include the public authentication parameter. The execution logic of the Broadcast (r) function may include adding the number of the node requesting the Broadcast to the first node set, i.e., the storage of the change contract, i.e., the worldwide state of the contract, in addition to the above-described placement of the common verification parameter into the msg corresponding to the particular topic in the receipt. Assuming that consensus nodes 1-4 each send a transaction that invokes the function Broadcast (r) in the DKG contract, execution of the function Broadcast (r) includes storing the number 1-4 of the 4 consensus nodes that initiated the transaction in a first state maintained by the contract, e.g., in the form {1,2,3,4}, with { representing a set, e.g., named Parties set.

S330: each consensus node verifies each secret share and the corresponding public verification parameter, and sends the node number failing to verify to the contract through complaint transaction; the contract determines a second node set according to the node numbers and the first node set of verification failure sent by all the consensus nodes.

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

As mentioned in the foregoing S310, each consensus node generates n secret shares S _ij, reserves one share itself, and sends n-1 of them to the other n-1 nodes through the P2P network component and encryption, respectively. As mentioned in the foregoing S320, each node generates a public verification parameter corresponding to its own secret share and broadcasts it by means of an on-link contract.

If the secret share issued by each node and the corresponding public verification parameter are attributed to the same polynomial, the following equation should hold:

as previously described, t= quorum-1; n=4, quorum =3, when t=2.

Based on the nature of equation (5), each secret share and common verification parameter received can be verified using the equation. If the verification equation holds, it is stated that the secret share and the corresponding public verification parameter are attributed to the same polynomial, otherwise not. This also makes it possible to check whether there is a wrongly acting node generating the secret share and the corresponding public verification parameter. Typical bad actions are e.g. the node generating S _ij according to the first polynomial, but again a _ik was generated with a different polynomial (k=0, once again, t).

The above verification, in particular:

when j=1, i.e. consensus node 1 can verify the following:

i＝1： (in fact, consensus node 1 may not verify whether this equation holds because both the secret share S ₁₁ and the verification parameter < A ₁₁,A₁₂,A₁₃ > are self-generated)

i＝2：

i＝3：

i＝4：

If the equation corresponding to i=2 is not established, the consensus node 1 may send the node number 2, through which the verification is not passed, to the DKG contract. Similarly, if the equations corresponding to i=2, 3 are not satisfied, the consensus node 1 may send the node numbers 2,3, which do not pass the verification, to the DKG contract. Similarly, if the equation corresponding to i=2, 3,4 is not satisfied, the consensus node 1 may send the node number 2,3, 4 that the verification does not pass to the DKG contract.

J=2, i.e. consensus node 2 can verify the following:

i＝1：

i＝2： (in fact, the consensus node 2 may not verify whether this equation holds, because both the secret share S ₂₂ and the verification parameter < A ₂₀,A₂₁,A₂₂ > are self-generated)

i＝3：

i＝4：

If the equation corresponding to i=1 is not established, the consensus node 2 may transmit the node number 1, through which the verification is not passed, to the DKG contract. Similarly, if the equations corresponding to i=1, 3 are not satisfied, the consensus node 2 may send the node numbers 1,3, which do not pass the verification, to the DKG contract. Similarly, if the equations corresponding to i=1, 3,4 are not satisfied, the consensus node 2 may send the node numbers 1,3, 4, which do not pass the verification, to the DKG contract.

J=3, i.e. consensus node 3 can verify the following:

i＝1：

i＝2：

i＝3： (in fact, the consensus node 3 may not verify whether this equation holds, because both the secret share S ₃₃ and the verification parameter < A ₃₀,A₃₁,A₃₂ > are self-generated)

i＝4：

If the equation corresponding to i=1 is not established, the consensus node 3 may transmit the node number 1, through which the verification is not passed, to the DKG contract. Similarly, if the equation corresponding to i=1, 2 does not hold, the consensus node 3 may send the node number 1, 2 that the verification does not pass to the DKG contract. Similarly, if the equation corresponding to i=1, 2, 4 is not established, the consensus node 3 may send the node number 1, 2, 4, through which the verification is not passed, to the DKG contract.

J=4, i.e. consensus node 4 can verify the following:

i＝1：

i＝2：

i＝3：

i＝4： (in fact, the consensus node 4 may not verify whether this equation holds, because both the secret share S ₄₄ and the verification parameter < A ₄₀,A₄₁,A₄₂ > are self-generated)

If the equation corresponding to i=1 is not established, the consensus node 4 may transmit the node number 1, through which the verification is not passed, to the DKG contract. Similarly, if the equation corresponding to i=1, 2 does not hold, the consensus node 4 may send the node number 1, 2 that the verification does not pass to the DKG contract. Similarly, if the equation corresponding to i=1, 2,3 does not hold, the consensus node 4 may send the node number 1, 2,3 that the verification does not pass to the DKG contract.

A transaction may be signed by each node with its own private key onto the blockchain, e.g., a node sends a node number that failed in verification to the blockchain network by initiating a transaction, e.g., a complaint transaction, that may invoke a function of Confirm (r) in the DKG contract, where the function may include the parameter r, which may include the node number that failed in verification submitted by the node in the complaint transaction.

Execution logic of the function of Confirm (r) may include copying the node number in the first set of nodes Parties that did not receive the complaint transaction 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, e.g., the parameter r=4 included in the function that invokes Confirm (r) in the complaint transaction initiated by consensus node 1, the DKG contract marks 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 the corresponding complaints, node numbers 1,2,3 in the first node set remain. Thus, the DKG contract can determine a second set of nodes {1,2,3} from the node number 4 and the first set of nodes {1,2,3,4} of authentication failure from the respective consensus nodes, the second set of nodes being named QUAL, for example.

It should be noted that, in a blockchain network, execution of contracts is not necessarily performed in the same block, but may be performed in different blocks, respectively, due to semi-synchronous or asynchronous network characteristics. In this case, the state machine may typically be set up in the contract again, to transition the state of the state machine if a portion is executed, or until the state machine transitions to some final state. Each step performed by the state machine may be performed 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 parameter and the second node set, and calculates a private key share corresponding to the consensus node based on the local secret share and the node set in the contract.

In one aspect, each consensus node may calculate a public key share locally based on the validation parameters and the set of nodes in the contract, which public key share may be calculated according to the following formula:

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

similarly, for example, the public key shares calculated by consensus node 2 may be:

similarly, the public key shares calculated by the consensus node 3 may be, for example:

similarly, the public key shares calculated by the consensus node 4 may be, for example:

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

x _j＝∑_i∈QUALs_ij mod q formula (7)

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

The consensus node2 locally calculates its own private key share:

the consensus node 3 locally calculates its own private key share:

the consensus node 4 locally calculates its own private key share:

It can be seen that the private key shares calculated by node 1, node 2, node 3 and node 4 are not the same.

In yet another aspect, each consensus node may each calculate a total public key locally based on the validation parameters and the set of nodes in the contract, which may be calculated according to the following formula:

y= pi _i∈QUALy_i formula (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, i.e. the nodes obtain the same total public key by the method.

The private key share x ₁ corresponds to the public key share pub ₁, the private key share x ₂ corresponds to the public key share pub ₂, the private key share x ₃ corresponds to the public key share pub ₃, and the private key share x ₄ corresponds to the public key share pub ₄. As previously described, each public key share may verify the signature share made by the corresponding private key share. Moreover, a complete signature of the signature shares generated by at least quorum private key shares recovered by the recovery function can be verified by the corresponding 1 total public key.

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

It can be seen that assuming node 4 is disliked, the secret shares and the corresponding public verification parameters thereof are not generated according to the same polynomial, and thus are failed to be verified by at least one node and complaint is caused, then node 4 is not included in the second set of nodes, and then the public key shares are calculated by at least nodes 1, 2 and 3 according to the public verification parameters generated by node 4 but according to the public verification parameters generated by nodes 1, 2 and 3 in the second set of nodes.

Each consensus node calculates its own corresponding private key share based on the local secret share and the set of nodes in the contract.

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

The consensus node2 locally calculates its own private key share:

the consensus node 3 locally calculates its own private key share:

the consensus node 4 locally calculates its own private key share:

It can be seen that assuming node 4 is disliked, the secret shares and the corresponding public verification parameters thereof are not generated according to the same polynomial, and thus are failed to be verified by at least one node and complain is initiated, then node 4 is not included in the second set of nodes, and the secret shares generated by node 4 are not relied upon in the process of calculating the private key shares by at least nodes 1, 2 and 3, but rather by nodes 1, 2 and 3 in the second set of nodes. Moreover, at least the private key shares calculated by node 1, node 2 and node 3 are different.

Each consensus node may each calculate a total public key locally based on the validation parameters and the set of nodes in the contract.

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 node 4 is disliked, its secret share and corresponding public verification parameters are not generated according to the same polynomial, and thus fails to be verified by at least one node and complains, the second node set does not include node 4, and at least nodes 1, 2 and 3 do not depend on the public verification parameters generated by node 4 in the process of calculating the total public key, but depend on the public verification parameters generated by nodes 1, 2 and 3 in the second node set. Moreover, at least the node 1, the node 2 and the node 3 have the same calculated total public key, i.e. at least the honest node obtains the same total public key by the method.

Thus, for a consensus node with a total number of n, a threshold signature algorithm is used, where it is expected that any at least w signature shares of the m signature shares can be recovered to a complete signature, if no disliked node is present, i.e. the secret share and the corresponding public verification parameter are generated according to the same polynomial, where n may be equal to m. If there are bad nodes, e.g. b bad nodes, then m=n-b, while w remains unchanged, but m needs to be ensured not to be smaller than w, otherwise the threshold signature algorithm fails.

In S330, each consensus node verifies each received secret share and the corresponding public verification parameter, and if verification fails, a complaint transaction may be signed by the verification node with its private key and sent to the blockchain. Specifically, the transaction may call the function Confirms (r) in the DKG contract, where the function may include the parameter r, which may include the node number of the verification failure submitted by the node in the complaint transaction. For example, node j receives the secret share S _ij sent by node i encrypted in S310, and the receiving node j verifies S _ij sent by i using equation (5). Typically, in the case that the verification is not passed, and that S _ij sent by the node i does not correspond to the public verification parameter generated by the node i and broadcast by the on-link contract, the node j that receives this secret share S _ij may perform the verification in S330, and may send the number i of this node to the DKG contract after the verification is not passed. In order to prove that the secret share sent by node i has not been tampered with, node j may send this secret share of node i along with the signature to the DKG contract, in addition to the number i of this node. It is also mentioned in the aforementioned S310 that the node may sign the generated and issued secret shares. In order to enable the DKG contract to verify the secret share and the corresponding public verification parameters, it is necessary to include the plaintext of the secret share in the complaint transaction, i.e. the plaintext obtained after node j decrypts the encrypted secret share of node i. In order to enable the DKG contract to verify the signature, it is preferable that in S310, the node i signs the secret share first, encrypts the secret share in the clear together with the signature, and then transmits the encrypted secret share to the node j, that is, the common node that generates the secret share signs the generated secret share and encrypts and transmits 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 secret share of the plaintext sent by the node i to the node j and the signature of the generator i on the generated secret share of the plaintext.

Before the DKG contract determines the second node set according to the node number and the first node set that fail to verify sent by each consensus node, the DKG contract may first verify the signature of the secret share in the complaint transaction, and if verification is correct, it may confirm that the secret share originally sent to node j by node i in the above example has not been tampered. Further, the DKG contract may verify whether the secret share and the corresponding public verification parameter belong to the same polynomial, e.g. according to the aforementioned formula (5). If the verification equation is not established according to the formula (5), it can be confirmed that the secret share and the corresponding public verification parameter do not belong to the same polynomial, and the complaint is established; if the verification equation is established according to equation (5), it can be confirmed that the verification of the secret share and the corresponding common verification parameter belongs to the same polynomial, and the complaint is not established. For complaints to be met, i.e., to confirm verification failure, the DKG contract may determine a second set of nodes based on the node number and the first set of nodes in the complaint transaction. For example, node number 4 is included in the complaint transaction, then as in the previous example, the DKG contract may mark node number 4 in the first set of nodes Parties as deleted, the first set of nodes Parties = {1,2,3,4}. Further, the DKG contract can determine the second set of nodes qual= {1,2,3} from the set of node numbers 4 and Parties {1,2,3,4} that failed to verify. While not true for complaints, i.e., failure to confirm verification, the DKG contract does not mark node number 4 in the first node set Parties as deleted, nor does it set QUAL to {1,2,3}, accordingly, but still holds {1,2,3,4}.

Furthermore, it is possible that during the previous distributed key generation, the secret share sent by node i to node j does not agree with the public verification parameter generated by the corresponding node i, so that the complaint transaction of node j to node i is successful, whereas during the subsequent distributed key generation, the secret share sent by node i to node j is actually agreed with the public verification parameter generated by the corresponding node i. In this case, node j may still initiate a complaint transaction with the clear secret share and signature of node i of the previous round in the latter round, thereby misjudging the DKG contract in the latter round. Obviously this is a malicious complaint. In this regard, in each round of distributed key generation, a sequence number, e.g., epoch, may be included in the initiated transaction that indicates the round of distributed key generation. Each time a new round of distributed key generation is performed, epoch may be incremented by 1 based on the original value. Thus, in S310, the secret share generated and transmitted by the node i and the epoch may be signed together and then encrypted. Furthermore, in the distributed key generation process of epoch=p, if node i is bad, node j can send the number of node i with failed verification and the secret share of plaintext sent by node i to node j, epoch=p and signature through complaint transaction, so that DKG contract can verify after receiving the complaint transaction, and can verify that the secret share of plaintext in original message, epoch=p has not been tampered through signature first. In this way, in the distributed key generation process of epoch=p+1, assuming that node i is not bad, node j can verify the original message through the signature to tamper without trust of the present complaint after receiving the complaint transaction even though the number of node i with failed verification is sent by the complaint transaction and the secret share of the plaintext sent by node i to node j, epoch=p+1 and the signature of the previous round are the same as those of the original message, so that the malicious complaint is avoided.

It should be noted that, the above-mentioned sending of the plaintext secret share in S330 occurs on the premise that the honest node must respond correctly within a certain time. In this way, the private key shares are not compromised by sending all of the secret shares, and the final complete signature is not compromised.

In S320, the common authentication parameters broadcast by each consensus node through the on-link contracts are also accompanied by the round. In this way, the turn to which the common authentication parameter belongs can be distinguished in the presence of a delay in the network.

By the method, on the basis of guaranteeing the overall consistency and synchronization of the blockchain network by a consensus mechanism, the distributed key generation is realized by combining the blockchain intelligent contracts, so that the generation of the distributed key is guaranteed to be generated by each participant through cooperation on one hand, and on the other hand, the generated result is consistent and reliable, thereby getting rid of the strong dependence of the original blockchain on network synchronization for realizing the generation of the distributed key, and solving the problem of unreliability of the generated result under the condition.

The foregoing is that the solution provided in this specification occurs on the premise that the honest node must respond correctly within a certain time. The time period may be realized 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, a separate process other than the blockchain platform process running on the blockchain node or a thread or coroutine in the blockchain platform process, and the like. For convenience, this physical or logical entity is referred to herein collectively as a DKG controller.

The timer maintained by the DKG controller needs to be triggered to start by an activation signal. The enable signal may be a received system instruction or an event on a received blockchain. The former is, for example, a system instruction issued by an account with administrator rights, and the latter is, for example, a specific event on some blockchain. For the case of receiving an event on a blockchain, the DKG controller can monitor a particular topic in the receipt to obtain a particular event and msg content, the principle being as described previously. The following description uses a DKG controller as a thread or coroutine in a blockchain platform process, and the DKG controller receives an event on a blockchain. It is still assumed here that the blockchain network includes 4 consensus nodes numbered 1,2, 3, 4, respectively.

After receiving the start signal, the DKG controller on the node 1 (hereinafter referred to as DKG controller 1) may issue a transaction with the private key of the node 1, and the transaction may invoke a DKG contract. This initiation transaction that invokes the DKG contract may specifically be a call DKGStart () function that is meant to initiate the distributed key generation process of the present round. After invoking DKGStart () function, the execution logic of DKGStart () function may include adding 1 to the value of epoch. Also, after execution of the contract, an event for a particular topic may be generated in the receipt and this epoch added to the corresponding msg. As described above, in each round of transactions initiated, for example, epoch carrying the present round, on one hand, the round to which the transaction belongs may be distinguished, for example, the round to which the public verification parameter belongs may be distinguished, and on the other hand, malicious complaints may be avoided.

The DKG controller 1 can register with the block link point for listening to events followed by subscribing to a specific topic event. Upon hearing the relevant event, DKG controller 1 may determine that the previously initiated transaction calling DKGStart () contract has been performed and may obtain the current epoch value from the receipt. In this way, the DKG controller 1 can start a timer. This timer may be timed according to the number of outgoing blocks, or rather counts, the number of blocks generated on the blockchain. The starting point of the start timer may be the block number of the block for which the transaction calling DKGStart () contract was performed. The DKG controller 1 can set a timeout time for its maintained timer (hereinafter referred to as timer 1), which is, for example, a certain number of blocks, for example, 10 blocks, indicating a block number of 10 plus from the starting block number. For example, DKG controller 1 could start timer 1 listening from the blockchain that a transaction previously initiated to invoke DKGStart () contract was executed in block 100. The timer 1 may start counting from block 100 and take 10 blocks as timeout time, i.e. to block 110.

After the DKG controller 1 starts the timer 1, the polynomial may also be generated as described in S310, and further, S ₁₁,S₁₂,S₁₃ and S ₁₄ of 4 secret shares are generated (of course, the polynomial and the secret shares and the public verification parameters may also be generated before starting the timer 1, and the following steps are similar and are not repeated). The DKG controller 1 can itself reserve S ₁₁ and send the other three secret shares to the other 3 consensus nodes by encryption through the P2P network component, respectively. For example, S ₁₂ sends to node 2, S ₁₃ sends to node 3, and S ₁₄ sends to node 4.

Furthermore, the node 1 may also generate a public verification parameter corresponding to its own secret share and broadcast by an on-link contract, as described in S320.

The DKG controller 1 can monitor the out-of-block situation of the blockchain. The blockchain network continues to run, new blocks continue to be generated, and the block numbers are correspondingly incremented by 1. The DKG controller 1 can continuously monitor the current latest block number.

The DKG controller 2 on node 2 could also monitor the receipt and, after having monitored the event that the transaction of DKGStart () contract has been performed, could obtain the current epoch value from the receipt. Further, the DKG controller 2 may start the timer 2. For example, DKG controller 2 listens to the DKGStart () contract of the latest epoch from the blockchain executing in block No. 100, timer 2 can be started. The timeout time is uniformly set to 10 blocks, for example. The timer 2 may start counting from block 100 and take 10 blocks as timeout time, i.e. to block 110.

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

Similarly, the DKG controller 3 on node 3 may also monitor the receipt and, after having monitored the event that the transaction of DKGStart () 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, DKG controller 3 listens to the DKGStart () contract of the latest epoch from the blockchain executing in block No. 100, then timer 3 can be started. The timeout time is uniformly set to 10 blocks, for example. The timer 3 may start counting from block 100 and take 10 blocks as timeout time, i.e. to block 110.

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

Similarly, the DKG controller 4 on node 4 may also monitor the receipt and, after having monitored the event that the transaction of DKGStart () 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, DKG controller 4 listens to the DKGStart () contract of the latest epoch from the blockchain executing in block No. 100, timer 4 may be started. The timeout time is uniformly set to 10 blocks, for example. The timer 4 may start counting from block 100 and take 10 blocks as timeout time, i.e. to block 110.

After the DKG controller 4 starts the timer 4, the polynomial may also be generated as described in S310, thereby generating S ₄₁,S₄₂,S₄₃ and S ₄₄ of 4 secret shares. The DKG controller 4 may itself reserve S ₄₄ and send the other three secret shares to the other 3 consensus nodes, respectively, encrypted by the P2P network component. For example, S ₄₁ sends to node 1, S ₄₂ sends to node 2, and S ₄₃ sends to node 3. Furthermore, the node 4 may also generate a public verification parameter corresponding to its own secret share and broadcast by the on-link contract, as described in S320.

A specific procedure for broadcasting public verification parameters via on-chain contracts may be for each node to sign a transaction with its own private key to be sent to the blockchain, as previously described. Here, for example, the transaction calls the Broadcast () function in the DKG contract, and the incoming parameters include the public authentication parameters generated by the node itself and epoch.

For example, DKG controller 1 listens from the blockchain that the transaction previously initiated to invoke DKGStart () contract was executed in block 100, starting timer 1. Further, after the DKG controller 1 generates the secret share and the corresponding public verification parameters, S ₁₂ is sent to the node 2 through the P2P network component, S ₁₃ is sent to the node 3 through the P2P network component, S ₁₄ is sent to the node 4 through the P2P network component, and the transaction call Broadcast () function is initiated, and the incoming parameters include the public verification parameters generated by the DKG controller 1 itself and the current epoch. Further, the result of the Broadcast () function execution may include adding the number of node 1 to Parties sets. The transaction where the Broadcast () function is located is executed, for example, in block 102, and the execution result includes Parties = {1}.

There may be different delays in the message store in the network.

Thus, for example, DKG controller 2 listens from the blockchain that the transaction previously initiated to invoke DKGStart () contract was executed in block 100, starting timer 2. Further, after the DKG controller 2 generates the secret share and the corresponding public verification parameters, S ₂₁ is sent to the node 1 through the P2P network component, S ₂₃ is sent to the node 3 through the P2P network component, S ₂₄ is sent to the node 4 through the P2P network component, and the transaction call Broadcast () function is initiated, and the incoming parameters include the public verification parameters generated by the DKG controller 2 and the current epoch. Further, the result of the Broadcast () function execution may include adding the number of node 2 to Parties sets. The transaction where the Broadcast () function is located is executed, for example, in block 103, and the execution result includes Parties = {1,2}.

Similarly, a transaction that previously initiated a call DKGStart () contract is executed in block 100, such as the DKG controller 3 listening from the blockchain, starting timer 3. Further, after the DKG controller 3 generates the secret share and the corresponding public verification parameters, S ₃₁ is sent to the node 1 through the P2P network component, S ₃₂ is sent to the node 2 through the P2P network component, S ₃₄ is sent to the node 4 through the P2P network component, and the transaction call Broadcast () function is initiated, and the incoming parameters include the public verification parameters generated by the DKG controller 3 itself and the current epoch. Further, the result of the Broadcast () function execution may include adding the number of node 3 to Parties sets. The transaction where the Broadcast () function is located is executed, for example, in block 104, and the execution result includes Parties = {1,2,3}.

Similarly, a transaction that, for example, DKG controller 4 should have heard from the blockchain before initiating a call DKGStart () contract is executed in block 100, starting timer 4. Further, the DKG controller 4 should generate a secret share and corresponding public authentication parameters, should send S ₄₁ to node 1 through the P2P network component, should send S ₄₂ to node 2 through the P2P network component, should send S ₄₃ to node 3 through the P2P network component, and initiate a transaction call Broadcast () function, the incoming parameters including the public authentication parameters and current epoch generated by the DKG controller 4 itself. Further, the result of the Broadcast () function execution includes adding the number of node 4 to the Parties set. The transaction where the Broadcast () function is located is executed, for example, in block 105, and the execution result includes Parties = {1,2,3,4}.

But may be due to delay, packet loss, etc. errors or node 4 dislikes, resulting in at least one of nodes 1, 2, 3 not receiving the corresponding S ₄₁、S₄₂、S₄₃ during the timeout, e.g., node 1 not receiving S ₄₁ during the timeout. Specifically, as described above, the DKG controller 1 can monitor the out-of-block situation of the blockchain. The blockchain network continues to run, new blocks continue to be generated, and the block numbers are correspondingly incremented by 1. The DKG controller 1 may continuously monitor the current latest block number, and after the timeout period arrives, that is, after monitoring that the 110 th block is generated on the blockchain, if S ₄₁ is still not received, the node 1 may initiate a retransmission request. The retransmission request may specifically be a transaction signed by node 1, which may call a function named RetransitRequest () in a DKG contract, for example, and the input parameters may be, for example, the source node and the destination node number requesting to retransmit the secret share, where the source node P _i =4 and the destination node P _j =1 due to the need to retransmit S ₄₁. In addition, an epoch parameter can be added, and the subsequent retransmission secret share transaction can also be added to the epoch parameter, and the description is omitted.

By sending the transaction to the contract, the contract can broadcast the numbers of the source node and the target node requesting retransmission of the secret share. Node 4 may snoop the execution of the transaction by listening for a particular topic event in the receipt (e.g., retransitRequest event), and if it is determined that a self-retransmission of the secret share is required, may initiate a transaction to retransmit the secret share to the node 1 and/or to the DKG contract, e.g., invoking the RetransitResponse () function in the DKG contract. The transaction for retransmitting the secret shares may include the secret shares S ₄₁ of plaintext or ciphertext and may also include epoch. The final private key share in this way remains secure, given that the honest node must respond correctly within a certain time, and that the polynomial is not disclosed due to the plaintext of the individual secret share being uplinked.

In this way, node 1 may receive the broadcasted re-transmitted secret shares, e.g. by listening for events of a specific topic in the receipt (e.g. RetransitResponse events), as described previously, to obtain the re-transmitted secret shares in the corresponding msg. The retransmitted secret shares received by node 1 may be ciphertext or plaintext. For ciphertext, node 1 may decrypt it to obtain plaintext. The node 1 may verify the retransmitted plaintext secret shares or the decrypted plaintext secret shares with the corresponding public verification parameters. If the authentication is successful, node 1 may continue to perform subsequent distributed key generation processes. If the verification fails, the node 1 may send the node number that failed the verification to the contract through a complaint transaction; the contract determines the second set of nodes based on the node number and the first set of nodes from each consensus node that failed the verification, as previously described.

Furthermore, if the DKG contract receives a secret share that the node 4 has retransmitted by retransmitting the secret share transaction, the DKG contract may also verify the retransmitted plain secret share and the corresponding public verification parameters if the retransmitted secret share is plain text. If the verification is successful, the DKG contract can broadcast the retransmitted secret share so that node 1 can receive the retransmitted secret share, and further, as previously described, node 1 can perform a subsequent distributed key generation process; if the authentication fails, the DKG contract determines a second node set according to the node number and the first node set that failed the authentication, as previously described.

The node 4 may prevent the node1 from misreporting that the retransmitted secret share was not received by retransmitting the secret share trade the retransmitted secret share to the DKG contract, thereby preventing such misbehavior.

The timeout time is used to check whether the node 4 sends the secret share to the node 1 for timeout and/or to check whether the node 4 sends the corresponding public authentication parameter to the DKG contract for timeout. This timeout may be a first timeout.

After the first timeout period has elapsed, node 1 may not receive the secret share sent by node 4, and node 1 may then send the number of node 4 to the contract and broadcast via the contract by retransmitting the secret share request transaction. Also due to network delay, packet loss, etc., the node 1 may not initiate the retransmission secret share request transaction to the DKG contract within a reasonable time frame. Thus, a second timer may be set to limit the DKG contract to receive the retransmission secret share request transaction within a second timeout period. For example, it may be set to start simultaneously with the first timer or after the first timer expires. Thus, each consensus node may start a second timer on the same block, e.g., until node 1,2, 3 starts the second timer after monitoring that the DKGStart () function in the DKG contract of the latest epoch is executed in block 100, or until block 110 monitors that the first timeout expires. The second timer may time a second timeout. In this way, each node can verify that the retransmission secret share request transaction initiated by node 1 is within the second timeout period. Assume that the second timeout is 10 blocks. Continuing the previous example, if node 1 initiates a retransmission secret share request transaction within the number 120 block, nodes 2, 3, 4 can verify that the block number of the block that was processed most recently locally is within a second timeout period after receiving the transaction, and can then process the transaction; if node 1 initiates a retransmission secret share request transaction to the DKG contract after block number 120, nodes 2, 3, 4 can verify that the block number of the locally most recently processed block is outside of the second timeout period after receiving the transaction, and can discard the transaction without processing. The processing of the transaction may be the DKG controller sending the transaction to a DKG contract, which in turn may broadcast the retransmitted secret share over the contract.

In addition, the second timer may be set in the DKG contract to start a rule and a second timeout period. Taking the latter example, assume that the second timeout is 10 blocks. Continuing the foregoing example, if node 1 initiates a retransmission secret share request transaction to the DKG contract within block number 120, the DKG contract, when executed, may verify that the retransmission secret share request transaction initiated by node 1 is within a second timeout time, and may then process the transaction; if node 1 initiates a re-transmit secret share request transaction to the DKG contract after block number 120, the DKG contract, when executed, may verify that the re-transmit secret share request transaction initiated by node 1 is outside of the second timeout period, and may discard the transaction without processing. The processing of the transaction may be logic in a DKG contract execution contract and broadcasting the retransmission secret share request message through the contract.

Similarly, node 4, upon receiving the broadcasted request for retransmission of the secret shares, retransmits the secret shares to the DKG contract by retransmitting the secret share transaction. The DKG controller of node 1 may also set a timer to time a timeout, e.g. a third timeout, which may be a third timer. The DKG contract may also set the start rule for the third timer timeout time. The received retransmission secret shares before the third timeout time arrives, the node 1 or the DKG contract may process normally, otherwise discard. When the third timeout is started after the second timeout arrives, whether the retransmission secret share transaction is initiated within the range of (the second timeout+the third timeout) can be verified; in the case where the second timer is started together with the third timer, it may be verified whether the re-transmission of the secret share transaction is initiated within the third timeout period. In both cases it can be verified in practice whether the transaction for retransmitting the secret share is initiated before the third timeout has arrived. Here, the initiation may refer to the recording into the packaged block. The normal process, for the DKG controller 1 of node 1, may send the transaction to the DKG contract; for DKG contracts, the retransmitted clear secret share may be verified with the corresponding public verification parameters. If the verification is passed, the retransmitted secret share may be broadcasted by the DKG contract so that the node 1 may receive the retransmitted secret share, and further, as previously described, the node 1 may perform a subsequent distributed key generation process; if the authentication is not passed, as described above, the DKG contract may mark node 4 as a node that failed the authentication, and further determine a second set of nodes and a subsequent distributed key generation process based on the node number and the first set of nodes that failed the authentication. By reasonably setting the third timeout time, the problem that honest nodes have no opportunity to complain due to malicious complaint of other honest nodes before the Bayesian node reaches the first timeout time can be prevented. For the honest node receiving the malicious complaint, the contract can be checked as long as the transaction of retransmitting the secret share is initiated before the third timeout time is reached, so that the secret share which is initiated and retransmitted by the honest node can be proved to be correct, and the honest node can normally participate in the DKG process.

Through the setting of the first timeout time, the second timeout time and the third timeout time, the DKG process can be controlled to end within a reasonable time range, and the processing time of message interaction at different stages in the DKG process can be controlled.

The specification also provides a method for determining failure nodes in the distributed key generation process on the blockchain. Still similar to the previous assumption, each consensus node (which may contain the DKG controller of the node) should generate n secret shares and corresponding public verification parameters, should itself retain one secret share after receiving the signal to start timing, should send the other n-1 secret shares to the other n-1 nodes separately encrypted, and should broadcast the public verification parameters corresponding to the secret shares by on-chain contracts; the contract should add the number of the node requesting the broadcast to the first set of nodes.

Any of the consensus nodes sends the number of the second consensus node to the contract by retransmitting a secret share request transaction if the secret share of the second consensus node is not received within the first timeout.

The contract receives at least f+1 re-transmission secret share request transactions for the same node within a second timeout period, and marks the node as a node with failed verification. f is the maximum number of bad nodes in the hypothetical blockchain system, as previously described. This is because, for f+1 nodes, there are at most f bad nodes and at least 1 honest node. Thus, once a retransmission secret share request transaction for the same node issued by f+1 different nodes is reached, of which at least 1 must be issued by a honest node, although it is uncertain which at least 1 of the f+1 retransmission requests are issued by honest nodes, the f+1 retransmission requests as a whole are trusted, and thus the node for which the f+1 retransmission requests are directed can be marked as a node for which verification fails.

The method may further include the normal flow of DKG, that is, the contract determines the second node set according to the node number and the first node set that fail to verify, which is not described herein.

The following presents an embodiment of a blockchain system provided by the present specification, including a number of consensus nodes, wherein:

The first consensus node triggers and starts a first timer by a starting signal, and initiates a transaction for starting the generation of the distributed key of the round to the contract; the first timer is for counting a first timeout time.

Wherein the sending the secret share to the contract by retransmitting a secret share transaction includes the secret share of plaintext or ciphertext.

Wherein the contract also broadcasts the retransmitted secret share.

Wherein the first consensus node also receives the broadcasted re-transmitted secret shares and verifies the received secret shares with the corresponding public verification parameters.

Wherein if the authentication is successful, the first consensus node continues to perform the distributed key generation process.

If verification fails, the first consensus node sends the node number which fails to verify to the contract through complaint transaction; the contract determines a second set of nodes based on the node number and the first set of nodes that failed the verification.

And after receiving the transaction of the retransmission secret share of the second consensus node, if the retransmission secret share is plaintext, the contract also verifies the retransmission plaintext secret share and the corresponding public verification parameter.

Wherein the retransmitted secret share is broadcast if the verification is successful.

Wherein if the verification fails, the contract determines a second set of nodes based on the node number and the first set of nodes that failed the verification.

Wherein after the first consensus node sends the number of the second consensus node to the contract by retransmitting the secret share request transaction, further comprising:

The node or contract that received the retransmission secret share request transaction verifies whether the first consensus node initiated the retransmission secret share request transaction within a second timeout period;

If so, broadcasting the request for retransmission of the secret share through the contract;

If not, the re-transmission secret share request transaction is discarded.

Wherein, still include: the node or contract that received the retransmitted secret share transaction checks whether the second consensus node initiated the retransmitted secret share transaction before a third timeout time was reached;

If so, broadcasting the retransmitted secret share through the contract;

if not, the re-transmitted secret share transaction is discarded.

The following describes a system for implementing a determination failure node in a distributed key generation process on a blockchain, which includes a plurality of consensus nodes, wherein:

Wherein, still include:

the contract determines a second set of nodes based on the node number and the first set of nodes that failed the verification.

In the 90 s of the 20 th century, improvements to one technology could clearly be distinguished as improvements in hardware (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) or software (improvements to the process flow). However, with the development of technology, many improvements of the current method flows can be regarded as direct improvements of hardware circuit structures. Designers almost always obtain corresponding hardware circuit structures by programming improved method flows into hardware circuits. Therefore, an improvement of a method flow cannot be said to be realized by a hardware entity module. For example, a programmable logic device (Programmable Logic Device, PLD) (e.g., field programmable gate array (Field Programmable GATE ARRAY, FPGA)) is an integrated circuit whose logic functions are determined by user programming of the device. A designer programs to "integrate" a digital system onto a PLD without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Moreover, nowadays, instead of manually manufacturing integrated circuit chips, such programming is mostly implemented with "logic compiler (logic compiler)" software, which is similar to the software compiler used in program development and writing, and the original code before being compiled is also written in a specific programming language, which is called hardware description language (Hardware Description Language, HDL), but HDL is not just one, but a plurality of kinds, such as ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware Description Language)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(Ruby Hardware Description Language), and VHDL (Very-High-SPEED INTEGRATED Circuit Hardware Description Language) and Verilog are currently most commonly used. It will also be apparent to those skilled in the art that a hardware circuit implementing the logic method flow can be readily obtained by merely slightly programming the method flow into an integrated circuit using several of the hardware description languages described above.

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, application SPECIFIC INTEGRATED Circuits (ASICs), programmable logic controllers, and embedded microcontrollers, examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, atmel AT91SAM, microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic of the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller in a pure computer readable program code, it is well possible to implement the same functionality by logically programming the method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. Such a controller may thus be regarded as a kind of hardware component, and means for performing various functions included therein may also be regarded as structures within the hardware component. Or even means for achieving the various functions may be regarded as either software modules implementing the methods or structures within hardware components.

The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. One typical implementation device is a server system. Of course, this specification does not exclude that as future computer technology advances, the computer implementing the functions of the above-described embodiments may be, for example, a personal computer, a laptop computer, a car-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 means. The order of steps recited in the embodiments is merely one way of performing the order of steps and does not represent a unique order of execution. When implemented in an actual device or end product, the instructions may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even in a distributed data processing environment) as illustrated by the embodiments or by 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, it is not excluded that additional identical or equivalent elements may be present in a process, method, article, or apparatus that comprises a described element. For example, if first, second, etc. words are used to indicate a name, but not any particular order.

For convenience of description, the above devices are described as being functionally divided into various modules, respectively. Of course, when one or more of the present description is implemented, the functions of each module may be implemented in the same piece or pieces of software and/or hardware, or a module that implements the same function may be implemented by a plurality of sub-modules or a combination of sub-units, or the like. The above-described apparatus embodiments are merely illustrative, for example, the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The present description is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the specification. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations 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 one typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

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

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 storage media for a computer 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, read only 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, which can be used to store information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.

One skilled in the relevant art will recognize that 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. Moreover, one or more embodiments of the present description can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

One or more embodiments of the present specification 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 may 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.

In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for system embodiments, since they are substantially similar to method embodiments, the description is relatively simple, as relevant to see a section of the description of method embodiments. In the description of the present specification, a description referring to terms "one embodiment," "some embodiments," "examples," "specific examples," 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 present specification. In this specification, schematic representations of the above terms are not necessarily directed 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, the different embodiments or examples described in this specification and the features of the different embodiments or examples may be combined and combined by those skilled in the art without contradiction.

The foregoing is merely an example of one or more embodiments of the present specification and is not intended to limit the one or more embodiments of the present specification. Various modifications and alterations to one or more embodiments of this description will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement, or the like, which is within the spirit and principles of the present specification, should be included in the scope of the claims.

Claims

1. A method for realizing retransmission of secret shares in the process of distributed key generation on a block chain includes that each consensus node generates n secret shares and corresponding public verification parameters, after a timing starting signal is received, one secret share is reserved by itself, other n-1 secret shares are respectively sent to other n-1 nodes in an encryption mode, and the public verification parameters corresponding to the secret shares are broadcasted through on-chain contracts; the contract adds the number of the node requesting broadcasting to the first node set;

2. The method of claim 1, wherein the first consensus node is triggered by a start signal to start a first timer and initiates a transaction to the contract that initiates the distributed key generation of the round; the first timer is for counting a first timeout time.

3. The method of claim 1, the sending the secret shares to the contract by a retransmit secret share transaction, comprising the secret shares in plaintext or ciphertext.

4. The method of claim 3, the contract further broadcasting the retransmitted secret share.

5. A method as defined in claim 1, the first consensus node further receiving a broadcasted retransmission secret share and verifying the received secret share with a corresponding public verification parameter.

6. The method of claim 5, wherein the first consensus node continues to perform the distributed key generation process if the verification is successful.

7. The method of claim 5, wherein if verification fails, the first consensus node sends a node number that failed verification to the contract via a complaint transaction; the contract determines a second set of nodes based on the node number and the first set of nodes that failed the verification.

8. The method of claim 1, wherein after the contract receives the retransmitted secret share transaction of the second consensus node, the contract further verifies the retransmitted plaintext secret share and the corresponding public verification parameters if the retransmitted secret share is plaintext.

9. The method of claim 8, broadcasting the retransmitted secret share if the verification is successful.

10. The method of claim 8, wherein if the verification fails, the contract determines a second set of nodes based on the node number and the first set of nodes that failed the verification.

11. The method of claim 1, after the first consensus node sends the number of the second consensus node to the contract by retransmitting a secret share request transaction, further comprising:

A node or contract that receives a retransmission secret share request transaction checks whether the first consensus node initiates the retransmission secret share request transaction within a second timeout period;

If not, the re-transmission secret share request transaction is discarded.

12. The method of claim 1, further comprising: a node or contract that receives a re-transmitted secret share transaction checks whether the second consensus node initiates the re-transmitted secret share transaction before a third timeout time has arrived;

If so, broadcasting the retransmitted secret share through the contract;

if not, the re-transmitted secret share transaction is discarded.

13. A method for realizing the failure node determination in the distributed key generation process on a block chain includes that n secret shares and corresponding public verification parameters are generated in each of the nodes, after a timing starting signal is received, one secret share is reserved, other n-1 secret shares are respectively transmitted to other n-1 nodes in an encryption mode, and the public verification parameters corresponding to the secret shares are broadcasted through on-chain contracts; the contract adds the number of the node requesting broadcasting to the first node set;

14. The method of claim 13, further comprising:

15. A blockchain system comprising a number of consensus nodes, wherein:

16. A system for implementing a determination failure node in a distributed key generation process on a blockchain, comprising a plurality of consensus nodes, wherein:

Generating n secret shares and corresponding public verification parameters in each consensus node, after receiving a signal for starting timing, reserving one secret share by the self, respectively encrypting and transmitting other n-1 secret shares to other n-1 nodes, and broadcasting the public verification parameters corresponding to the secret shares through on-link contracts; the contract adds the number of the node requesting broadcasting to the first node set;