CN118473659A

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

Info

Publication number: CN118473659A
Application number: CN202410688789.8A
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-08-09
Also published as: CN114640451A

Abstract

A method, system, and consensus node for implementing distributed key generation on a blockchain, comprising: 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 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; each consensus node verifies each secret share and the corresponding public verification parameter; after each consensus node passes each verification, sending the node number passing the verification to the on-link contract; the contract determines a node set according to transactions sent by all consensus nodes; each consensus node calculates a public key share based on the public verification parameters and the node set locally, and calculates a private key share corresponding to the consensus node based on the local secret share and the node set.

Description

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

Technical Field

The embodiment of the specification belongs to the technical field of blockchains, and particularly relates to a method, a system and a consensus node 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, system, and consensus node for implementing distributed key generation on a blockchain, including:

A method of implementing distributed key generation on a blockchain, comprising:

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;

Each consensus node verifies each secret share and the corresponding public verification parameter;

After each consensus node passes each verification, sending the node number passing the verification to the on-link contract;

the G contract on the chain determines a node set according to transactions sent by all consensus nodes;

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

A method for implementing generation of random number seeds on a blockchain based on the method, comprising:

In the commit stage of PBFT, each consensus node signs an original message containing the unique value of the original transaction list in the consensus by adopting a private key share of the consensus node based on a threshold signature algorithm, generates a signature share, and adds the signature share into a broadcasted commit message;

After each consensus node collects at least quorum of commit messages, verifying signature shares in the received commit messages by adopting public key shares;

Each consensus node obtains a complete signature through a recovery function corresponding to a private key share generated by the threshold signature algorithm through at least quorum number of signature shares which are verified;

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

the first node receives secret shares generated by other nodes and receives corresponding public verification parameters through on-link contract broadcasting;

the first node verifies each secret share and the corresponding public verification parameter;

after each verification is passed by the first node, the node number passing the verification is sent to the on-link contract;

A first node receives a node set determined by the on-link contracts;

The first node calculates a public key share based on the public verification parameter and the node set, and calculates a private key share corresponding to the first node based on the secret share and the node set.

in the commit phase of PBFT, the first 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 a broadcasted commit message;

after the first node collects at least quorum of commit messages, verifying signature shares in the received commit messages by adopting public key shares;

the first node obtains a complete signature through a reply method corresponding to a private key share generated by the threshold signature algorithm through the signature share of at least quorum number of verification;

the first node obtains a random number seed based on the full signature.

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

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-chain contracts determine node sets according to transactions sent by all consensus nodes;

Each consensus node calculates a public key share based on the public verification parameters and the node set locally, and calculates a private key share corresponding to the consensus node based on the local secret share and the node set.

A first consensus node in a blockchain system, comprising:

the first consensus node receives secret shares generated by other nodes and receives corresponding public verification parameters through on-link contract broadcasting;

the first consensus node verifies each received secret share and the corresponding public verification parameter;

After each verification is passed by the first consensus node, the node number passing the verification is sent to the on-link contract;

the first consensus node receives a node set determined by the on-link contracts;

The first consensus node calculates a public key share based on the public verification parameter and the node set, and calculates a private key share corresponding to the first consensus node based on the secret share and the node set.

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 cooperation of all parties 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.

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 of distributed key generation in one embodiment of the present disclosure;

FIG. 8 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 tree) and generate a hash of a tree root of the Merkle tree (also referred to as a transaction root hash) based on the commonly recognized transaction data, and similarly, can construct a Merkle tree and generate a hash of a tree root of the Merkle tree (also referred to as a status root hash) based on the world status data, and can construct a Merkle tree and generate a hash of a tree root of the Merkle tree (also referred to as a receipt root hash) based on the receipt data. 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 comprising 4 consensus nodes, node 0 broadcasts itself generated signature shares σ3,0 to nodes 1, 2, 3 in S110, where subscript 3 of σ3,0 may represent the chunk 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. In this way, node 0 has already rolled up at least 3 signature shares, including self-broadcast signature shares σ3,0 and node 1, 2 broadcast signature shares σ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 quorum numbers.

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, the node 0 may calculate the signature shares σ3,1 by using the corresponding public key shares, to obtain a hash value, denoted as hash3,1; the node 0 can also perform the same hash calculation on the original message to obtain hash'3,1. If hash3,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 process. 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 in the block header of the generated current block.

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 previously described, a state root is a hash of the root of the MPT tree of the state composition of all accounts in the current block, pointing to state_root as a 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 a block number, and 0 may represent that this is the signature share of node 0; in S220, node 0 also receives signature shares σ3,1, σ3,2 broadcast by nodes 1, 2, respectively. In this way, node 0 has already rolled up at least 3 signature shares, including self-broadcast signature shares σ3,0 and node 1, 2 broadcast signature shares σ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 quorum numbers.

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

Through the steps of S210-S220 described above, the consensus node may normally obtain a complete signature. 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 in the block header of the generated current block.

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 (Elliptic 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:

fi (z) =ai0 +ai1z+ai2z2+ … + aitzt formula (1)

In equation (1), a _i0,a_i1,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:

fi (z) =ai 0+ai1z +ai2z2 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: f1 (z) =a10+a 11z+a12z2.

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: f2 (z) =a20+a 21z+a22z2.

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: f3 (z) =a30+a 31z+a32z2.

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: f4 (z) =a40+a41 z+a42z2.

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:

sij=fi (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 its own secret share and broadcasts via a DKG contract.

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 f content of the transaction includes, for example, a from field, a to field, a value field, a 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₃₂>.

S330: each consensus node verifies each received secret share and the corresponding public verification parameter.

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：

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：

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：

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)

S340: after each consensus node passes each verification, sending the node number passing the verification to the contract; the contract determines a node set according to the node numbers sent by the consensus nodes.

Consensus node 2 verifies the equationIf so, a transaction for calling the DKG contract can be initiated, wherein the transaction for calling the contract can be provided with the number of the node 1 so as to indicate that the secret share sent by the node 2 to the node 1 and the corresponding public verification parameter pass the verification; for example, a function (e.g., named confirm (v), where the parameter v is, for example, the number of the node that initiated the DKG to verify that the node was successful.

Consensus node 3 verifies the equationIf so, a transaction for calling the DKG contract can be initiated, wherein the transaction for calling the contract can be provided with the number of the node 1 so as to indicate that the secret share sent by the node 3 to the node 1 and the corresponding public verification parameter pass the verification; similarly, a call to a confirm (v) function in a DKG contract may be initiated.

Consensus node 4 verifies the equationIf so, a transaction for calling the DKG contract can be initiated, wherein the transaction for calling the contract can be provided with the number of the node 1 so as to indicate that the secret share sent by the node 4 to the node 1 and the corresponding public verification parameter pass the verification; similarly, a call to a confirm (v) function in a DKG contract may be initiated.

In this way, the DKG contract can collect the acknowledgements of node 1 passing the verification by all but node 1, and thus can consider that the secret shares issued by node 1 and the corresponding public verification parameters are all attributed to the same polynomial.

Similarly, the following is true:

Consensus node 1 verifies the equation If so, a transaction for calling the DKG contract can be initiated, wherein the transaction for calling the contract can be provided with the number of the node 2 so as to indicate that the secret share sent by the node 1 to the node 2 and the corresponding public verification parameter pass the verification; similarly, a call to a confirm (v) function in a DKG contract may be initiated.

Consensus node 3 verifies the equationIf so, a transaction for calling the DKG contract can be initiated, wherein the transaction for calling the contract can be provided with the number of the node 2 so as to indicate that the secret share sent by the node 3 to the node 2 and the corresponding public verification parameter pass the verification; similarly, a call to a confirm (v) function in a DKG contract may be initiated.

Consensus node 4 verifies the equationIf so, a transaction for calling the DKG contract can be initiated, wherein the transaction for calling the contract can be provided with the number of the node 2 so as to indicate that the secret share sent by the node 4 to the node 2 and the corresponding public verification parameter pass the verification; similarly, a call to a confirm (v) function in a DKG contract may be initiated.

In this way, the DKG contract can collect the acknowledgements that all nodes except node 2 pass the verification for node 2, so that the secret shares issued by node 2 and the corresponding public verification parameters can be considered to all belong to the same polynomial.

Similarly, the following is true:

Consensus node 1 verifies the equation If so, a transaction for calling the DKG contract can be initiated, wherein the transaction for calling the contract can be provided with the number of the node 1 so as to indicate that the secret share sent by the node 1 to the node 3 and the corresponding public verification parameter pass the verification; similarly, a call to a confirm (v) function in a DKG contract may be initiated.

Consensus node 2 verifies the equationIf so, a transaction for calling the DKG contract can be initiated, wherein the transaction for calling the contract can be provided with the number of the node 3 so as to indicate that the secret share sent by the node 2 to the node 3 and the corresponding public verification parameter pass the verification; similarly, a call to a confirm (v) function in a DKG contract may be initiated.

Consensus node 4 verifies the equationIf so, a transaction for calling the DKG contract can be initiated, wherein the transaction for calling the contract can be provided with the number of the node 1 so as to indicate that the secret share sent by the node 4 to the node 3 and the corresponding public verification parameter pass the verification; similarly, a call to a confirm (v) function in a DKG contract may be initiated.

In this way, the DKG contract can collect the acknowledgements that all nodes except node 3 pass the verification to node 3, so that the secret shares issued by node 3 and the corresponding public verification parameters can be considered to all belong to the same polynomial.

Similarly, the following is true:

Consensus node 1 verifies the equation If so, a transaction for calling the DKG contract can be initiated, wherein the transaction for calling the contract can be provided with the number of the node 1 so as to indicate that the secret share sent by the node 1 to the node 4 and the corresponding public verification parameter pass the verification; similarly, a call to a confirm (v) function in a DKG contract may be initiated.

Consensus node 2 verifies the equationIf so, a transaction for calling the DKG contract can be initiated, wherein the transaction for calling the contract can be provided with the number of the node 3 so as to indicate that the secret share sent by the node 2 to the node 4 and the corresponding public verification parameter pass the verification; similarly, a call to a confirm (v) function in a DKG contract may be initiated.

Consensus node 4 verifies the equationIf so, a transaction for calling the DKG contract can be initiated, wherein the transaction for calling the contract can be provided with the number of the node 1 so as to indicate that the secret share sent by the node 3 to the node 4 and the corresponding public verification parameter pass the verification; similarly, a call to a confirm (v) function in a DKG contract may be initiated.

In this way, the DKG contract can collect the acknowledgements of authentication by all nodes 4 except node 4, and thus can consider that the secret shares issued by node 4 and the corresponding public authentication parameters are all attributed to the same polynomial.

Further, the contract may determine the node set based on the node numbers sent by the consensus nodes.

For example, the DKG contract may determine a node set according to the transaction verification sent by each consensus node, specifically, for one node, if the DKG contract receives acknowledgements from all other nodes, the DKG contract adds the acknowledged node to the node set. This set is for example the QUAL set.

For example, in the example of S340, when the DKG contract received the acknowledgement of node 1 by node 2, node 3, and node 4, then the DKG contract adds node 1 to the QUAL set; similarly, if the DKG contract receives the acknowledgements from node 1, node 3, and node 4 for node 2, then the DKG contract adds node 2 to the QUAL set; similarly, if the DKG contract receives the acknowledgements from node 1, node 2, and node 4 to node 3, then the DKG contract adds node 3 to the QUAL set; similarly, if the DKG contract received the acknowledgements from node 1, node 2, and node 3 to node 4, then the DKG contract adds node 4 to the QUAL set.

Through the execution of the above contracts, the QUAL set includes node sets {1,2,3,4}.

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.

S350: each consensus node obtains the node set, calculates public key shares based on public verification parameters and the node set, and calculates private key shares corresponding to the consensus node based on local secret shares and the node set.

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

Thus, for example, the public key shares 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:

xj= Σie QUALsijmod q equation (7)

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

the consensus node 2 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 common verification parameters and the set of nodes in the contract, which may be calculated according to the following formula:

y= pi e QUALyi 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.

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.

A method for implementing distributed key generation on a blockchain is described below in connection with fig. 8 at the perspective of a consensus node, comprising:

s410, the first node receives secret shares generated by other nodes and receives corresponding public verification parameters through on-link contract broadcasting;

S420, the first consensus node verifies each received secret share and the corresponding public verification parameter;

S430, after each verification is passed, the first consensus node sends the node number passing the verification to the on-link contract;

s440, the first consensus node receives the node set determined by the on-link contracts;

s450, the first consensus node calculates a public key share based on the public verification parameter and the node set, and calculates a private key share corresponding to the first consensus node based on the secret share and the node set.

The first consensus node may also calculate a total public key based on the public verification parameters and the set of nodes.

Wherein the first node receives the secret shares generated by said other nodes via the P2P network component.

Wherein the first node also performs signature verification on the received secret shares generated by the other nodes.

Wherein the first node receives corresponding public verification parameters through on-link contract broadcasting, comprising:

The first node receives the common authentication parameters through an event listening mechanism of the blockchain.

The method for generating random number seeds on the blockchain is realized on the basis of the method, and comprises the following steps:

In the commit phase of PBFT, the first consensus node signs an original message containing the unique value of the original transaction list in the consensus by adopting a private key share of itself based on a threshold signature algorithm, generates a signature share, and adds the signature share to a broadcasted commit message;

After the first consensus node collects at least quorum of commit messages, verifying signature shares in the received commit messages by adopting public key shares;

The first consensus node obtains a complete signature through a recovery function corresponding to a private key share generated by the threshold signature algorithm through the verified signature share of at least quorum;

The first consensus node obtains a random number seed based on the full signature.

Wherein the unique values of the original transaction list include:

The original transaction list itself or a hash value of the original transaction list.

The original message further comprises a block number and/or a time stamp.

The original message also comprises a random number seed or a block hash generated in the last block.

Wherein further comprising:

the first consensus node places the resulting random number seed in the generated block header of the current block.

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

After each consensus node passes each verification, the node number passing the verification is sent to the on-chain contract;

Each consensus node may also calculate a total public key locally based on the public verification parameters and the set of nodes.

The following describes a first consensus node in a blockchain system provided by the present specification, including

After each verification is passed by the first consensus node, sending the node number passing the verification to the on-link contract;

In the 90s 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 description 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 of implementing distributed key generation on a blockchain, comprising:

After each consensus node passes each verification, sending the node number passing the verification to the contract; the contract determines a node set according to node numbers sent by all consensus nodes;

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

3. A method as defined in claim 1, the each consensus node to send n-1 of the generated n secret shares to other n-1 nodes, respectively, including with a P2P network component.

4. The method of claim 1, the each consensus node separately sending n-1 of the generated n secret shares to other n-1 nodes, comprising:

Each consensus node respectively sends n-1 secret shares in the generated n secret shares to other n-1 nodes after being signed.

5. The method of claim 1, the broadcasting public verification parameters by an on-link contract comprising:

broadcasting public verification parameters is achieved through an event mechanism of a block chain.

6. The method of claim 1, each consensus node further calculates a total public key based on the public verification parameters and the set of nodes, respectively.

7. A method of implementing generation of random number seeds on a blockchain on the basis of any of claims 1-6, comprising:

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

8. The method of claim 7, wherein the unique values of the original transaction list comprise:

9. The method of claim 7, wherein the original message further comprises a block number and/or a timestamp.

10. The method of claim 7, wherein the original message further comprises a random number seed or a block hash generated in a previous block.

11. The method of claim 7, further comprising:

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

12. A method of implementing distributed key generation on a blockchain, comprising:

A first node receives a node set determined by the on-link contracts;

13. A method as defined in claim 12, the first node receiving, via the P2P network component, the secret shares generated by the other nodes.

14. A method as defined in claim 12, the first node further performing signature verification on secret shares generated by the received other nodes.

15. The method of claim 12, the first node receiving the corresponding public verification parameters via an on-link contract broadcast, comprising:

16. The method of claim 12, each consensus node further calculates a total public key locally based on the common authentication parameter and the set of nodes.

17. A method of implementing generation of random number seeds on a blockchain on the basis of any of claims 12-16, comprising:

The first node obtains a complete signature through a recovery function corresponding to a private key share generated by the threshold signature algorithm through the signature share of at least quorum number of verification;

the first node obtains a random number seed based on the full signature.

18. The method of claim 17, wherein the unique values of the original transaction list comprise:

19. The method of claim 17, wherein the original message further comprises a block number and/or a timestamp.

20. The method of claim 17, wherein the original message further comprises a random number seed or a block hash generated in a previous block.

21. The method of claim 17, further comprising:

The first node places the resulting random number seed in the block header of the generated current block.

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

The contract determines a node set according to transactions sent by all consensus nodes;

23. A first consensus node in a blockchain system, comprising: