CN114640451A

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

Info

Publication number: CN114640451A
Application number: CN202210325828.9A
Authority: CN
Inventors: 李康
Original assignee: Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2022-03-29
Filing date: 2022-03-29
Publication date: 2022-06-17

Abstract

A method, a system and a consensus node for realizing distributed key generation on a block chain comprise: each consensus node generates n secret shares, reserves one secret share per consensus node, and encrypts and sends n-1 secret shares to other n-1 nodes respectively; each node generates public verification parameters corresponding to the own secret share and broadcasts the public verification parameters through a contract on the chain; each common identification node verifies each received secret share and the corresponding public verification parameter; after each consensus node passes each verification, the number of the verified node is sent to the contract on the chain; the contract determines a node set according to the transaction sent by each consensus node; each consensus node locally calculates a public key share based on the verification parameters and the node set, and calculates a corresponding private key share 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 block chains, and particularly relates to a method, a system and a consensus node for realizing distributed key generation on a block chain.

Background

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

Disclosure of Invention

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

a method for distributed key generation over a blockchain, comprising:

each consensus node generates n secret shares, reserves one secret share per consensus node, and encrypts and sends n-1 secret shares to other n-1 nodes respectively;

each consensus node generates a public verification parameter corresponding to the secret share of the consensus node and broadcasts the public verification parameter through a contract on the chain;

each common identification node verifies each received secret share and the corresponding public verification parameter;

after each common identification node passes each verification, the serial number of the verified node is sent to the contract on the chain;

determining a node set according to the transaction sent by each consensus node by the G contract on the chain;

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

A method for generating random number seeds on a block chain based on the above method, comprising:

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

after each consensus node collects the commit messages with at least the number of quorum, verifying the signature share in the received commit messages by adopting a public key share;

each common identification node obtains a complete signature by passing at least the verified quotients of the signatures through a recovery function corresponding to the share of the private keys generated by the threshold signature algorithm;

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

A method for distributed key generation over a blockchain, comprising:

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

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

after each verification is passed by the first node, the serial number of the node passing the verification is sent to the contract on the chain;

the first node receives the node set determined by the contract on the chain;

the first node calculates public key shares based on the verification parameters and the node set, and calculates corresponding private key shares based on the secret shares and the node set.

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

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

the first node obtains a complete signature by the signature shares of at least the number of the verified quotients of the signature through a reply method corresponding to the private key shares generated by the threshold signature algorithm;

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

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

each node generates public verification parameters corresponding to the own secret share and broadcasts the public verification parameters through a contract on the chain;

the contract on the chain determines a node set according to the transaction sent by each consensus node;

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

A first common node in a blockchain system, comprising:

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

the first common identification node verifies each received secret share and the corresponding common verification parameter;

after each verification is passed by the first recognition node, the serial number of the verified node is sent to the contract on the chain;

receiving a node set determined by the contract on the chain by a first common node;

the first common identification node calculates public key shares based on the verification parameters and the node set, and calculates corresponding private key shares based on the secret shares and the node set.

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

Drawings

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

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

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

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

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

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

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

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

Detailed Description

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

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

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

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

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

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

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

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

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

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

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

nodes

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

nodes

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

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

nodes

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

nodes

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

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

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

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

backup nodes

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

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

nodes

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

nodes

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

nodes

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

nodes

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

nodes

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

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

Considering that a number is generated for the content of this consensus in the process of consensus, if the consensus is completed, the generated number can be used as the block number of the block corresponding to this consensus, and therefore, the block number (i.e., the number) can also be used as the content in the original message. No matter whether the original transaction list contained in the (N +1) th block is the same as the original transaction list contained in the nth block, the block generation is sequential, which can be embodied as that the block number of the next block is the block number +1 of the previous block. Therefore, the block number is used as the content in the original message, even if the original transaction list contained in the (N +1) th block is the same as the original transaction list contained in the nth block, different signatures are obtained by each node based on the (original transaction list + block number) by adopting the own private key, the master node still cannot acquire the signatures of other nodes, so that the complete signature of the (N +1) th block cannot be predicted, and therefore the master node cannot predict the random number seed of the (N +1) th block by using the published random number seed of the (N) th block, and the purpose of unpredictable is achieved. Similarly to the numbering, the time stamp is also specific to one block, and the time stamp of the following block follows the previous block. 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 also have other content added, such as the random number seed generated in the previous block, i.e., the random number seed generated in the previous block may also be included in the original message. After the aforementioned a140 is performed, each node may generate the mth block based on the common transaction data, as described above. Since the mth block is generated by each node independently in the local area, if the hash values of the previous block generated by each node are not broadcast to each other among the link points of the block and compared, each node may not be able to determine whether the mth block generated in the block chain network is the same or whether the mth blocks generated on at least the quorum number of common nodes are the same from the viewpoint of overall availability of the block chain system. Through the generation process of the random number seeds in the present specification, the random number seeds of the same block should be the same, and the random number seeds in different blocks should be different, so that the random number seeds can be added to the original message. Thus, if the random number seeds corresponding to the mth block generated by each node are different, according to the property of the threshold signature algorithm, a complete signature may not be obtained through a recovery function in the process of generating the random number seeds of the (m +1) th block, so that the consensus node can be helped to confirm whether the previous blocks are consistent according to the scheme of the present specification. The hash value of the previous block can be used to replace the random number seed of the previous block, and since the hash value of one block is generally unique, the common node can also be helped to confirm whether the previous block is consistent.

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

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

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

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

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

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

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

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

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

nodes

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

nodes

1 and 2, respectively_3,1、σ_3,2. Thus, node 0 has collected at least 3 signature shares, including its own broadcast signature share σ_3,0And the signature share σ broadcast by the

nodes

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

s210: in the last stage of the consensus algorithm, the consensus node signs 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 to generate a signature share, and adds the signature share into the broadcasted consensus message.

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

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

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

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

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

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

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

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

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

nodes

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

nodes

1 and 2, respectively_3,1、σ_3,2. Thus, node 0 has collected at least 3 signature shares, including the signature shares that it broadcastsσ_3,0And the signature share σ broadcast by the

nodes

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

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

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

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

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

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

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

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

The present specification further provides a method for generating random numbers on a block chain, which may further include, based on the above S210-S230 methods: the consensus node generates a random number based on the generated random number 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, etc. In the threshold signature algorithm, 1 total public key and n public and private key pairs are generally required to be generated. In a typical and compact implementation, the number of private key shares may be equal to the number of consensus nodes, each consensus node holding one of the private keys, i.e. one private key share. In this way, each consensus node signs the original message by using its own private key share based on a threshold signature algorithm to generate a signature share. The minimum number of complete signatures generated by the recovery function, i.e. the threshold number w, may be equal to quorum in the PBFT algorithm, i.e. at least w signature shares may be used by the corresponding recovery function to generate a certain complete signature, regardless of which w of the n signature shares is, as long as the w signatures are signatures made of the same original message using the respective correct private key shares.

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

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

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

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

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

A method for implementing distributed key generation on a blockchain according to the present disclosure is described below with reference to fig. 7, where the method includes:

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

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

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

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

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

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

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

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

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

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

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

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

s_ij＝f_i(j) mod q (j ═ 1, …, n) equation (3)

In equation (3), q is the same large number used by each node, and is given to f_i(j) The purpose of modulo q is to get f_i(j) Is limited to [0, q-1 ]]Within the range of (1). For example:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

S320: each node generates a public authentication parameter corresponding to the own secret share and broadcasts the public authentication parameter through the DKG contract.

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

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

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

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

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

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

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

Event：

[topic][msg]

......

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

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

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

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

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

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

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

The consensus node 4 locally has secret shares S generated by different nodes₁₄、S₂₄、S₃₄、S₄₄And verifying the parameters<A₄₀,A₄₁,A₄₂>And can obtain common verification parameters 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 secret shares from any other node and receive common authentication parameters broadcast by contracts on the chain.

As mentioned in S310, each consensus node generates n secret shares S_ijAnd keeping one copy by itself, and sending n-1 secret shares to other n-1 nodes respectively through P2P network components and encryption. As mentioned in S320, each node generates its own secret share pairThe corresponding public authentication parameters are broadcast via the contract on the chain.

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

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

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

The verification specifically includes:

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

i＝1：

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

i＝2：

i＝3：

i＝4：

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

i＝1：

i＝2：

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

i＝3：

i＝4：

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

i＝1：

i＝2：

i＝3：

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

i＝4：

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

i＝1：

i＝2：

i＝3：

i＝4：

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

S340: after each common identification node passes each verification, sending the serial number of the verified node to the contract; the contract determines a node set according to the node numbers sent by the common nodes.

Consensus node 2 verification equation

If yes, a transaction for invoking the DKG contract can be initiated, and the transaction for invoking the contract can have the number of the node 1 to indicate that the secret share and the corresponding public verification parameter sent by the node 1 by the node 2 pass the verification; for example, it may be a function that initiates the success of the authentication node that calls the DKG (e.g., named confirm (v), where the parameter v is, for example, the number of the node that acknowledges).

Consensus node 3 validation equation

If so, a transaction may be initiated to invoke a DKG contract, which may have the number of node 1 to indicate the pair of nodes 3The secret share sent by the node 1 and the corresponding public verification parameter pass the inspection; similarly, a call to a confirm (v) function in the DKG contract may be initiated.

Consensus node 4 validation equation

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

In this way, the DKG contract can collect all the confirmations that node 1 is authenticated by nodes other than node 1, and thus can consider that the secret shares issued by node 1 and the corresponding common authentication parameters are all attributed to the same polynomial.

Similarly:

consensus node 1 validation equation

If yes, a transaction for invoking the DKG contract can be initiated, and the transaction for invoking the contract can have the number of the node 2 to indicate that the secret share and the corresponding public verification parameter sent by the node 2 by the node 1 pass the verification; similarly, a call to a confirm (v) function in the DKG contract may be initiated.

Consensus node 3 validation equation

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

Consensus node 4 validation equation

If so, a transaction may be initiated that invokes a DKG contract, the call toThe contract transaction may be accompanied by the node 2 number to indicate that the secret share issued by the node 4 to the node 2 and the corresponding public authentication parameter pass the verification; similarly, a call to the confirm (v) function in the DKG contract may be initiated.

In this way, the DKG contract can collect all the confirmations that node 2 is authenticated by nodes other than node 2, so the secret shares issued by node 2 and the corresponding common authentication parameters can be considered to be belonging to the same polynomial.

Similarly:

consensus node 1 validation equation

If yes, a transaction for invoking the DKG contract can be initiated, and the transaction for invoking the contract can have the number of the node 1 to indicate that the secret share and the corresponding public verification parameter sent by the node 3 by the node 1 pass the verification; similarly, a call to a confirm (v) function in the DKG contract may be initiated.

Consensus node 2 verification equation

If yes, a transaction for invoking the DKG contract can be initiated, and the transaction for invoking the contract can have the number of the node 3 to indicate that the secret share sent by the node 3 by the node 2 and the corresponding public verification parameter pass the verification; similarly, a call to a confirm (v) function in the DKG contract may be initiated.

Consensus node 4 validation equation

If yes, a transaction for invoking the DKG contract can be initiated, and the transaction for invoking the contract can have the number of the node 1 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 the confirm (v) function in the DKG contract may be initiated.

In this way, the DKG contract can collect all the confirmations that nodes 3 are authenticated by nodes other than node 3, so the secret shares issued by node 3 and the corresponding common authentication parameters can be considered to be belonging to the same polynomial.

Similarly, the following steps are carried out:

consensus node 1 verification equation

If yes, a transaction for invoking the DKG contract can be initiated, and the transaction for invoking the contract can have the number of the node 1 to indicate that the secret share and the corresponding public verification parameter sent by the node 4 by the node 1 pass the verification; similarly, a call to a confirm (v) function in the DKG contract may be initiated.

Consensus node 2 verification equation

If yes, a transaction for invoking the DKG contract can be initiated, and the transaction for invoking the contract can have the number of the node 3 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 the DKG contract may be initiated.

Consensus node 4 validation equation

If yes, a transaction for invoking the DKG contract can be initiated, and the transaction for invoking the contract can have the number of the node 1 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 the confirm (v) function in the DKG contract may be initiated.

In this way, the DKG contract can collect all the confirmations that nodes 4 are authenticated by nodes other than node 4, and thus can consider that the secret shares issued by nodes 4 and the corresponding common authentication parameters are all attributed to the same polynomial.

Further, the contract may determine a set of nodes based on node numbers from the respective consensus nodes.

For example, the DKG contract may determine a set of nodes based on transaction checks sent by the respective identified nodes, and specifically, for a node, if the DKG contract receives the confirmation from all other nodes, the DKG contract adds the confirmed node to the set of nodes. This set is for example a QUAL set.

For example, in the example of S340, the DKG contract received node 1 acknowledgements from node 2, node 3 and node 4, the DKG contract added node 1 to the QUAL set; similarly, the DKG contract receives node 2 acknowledgements from node 1, node 3 and node 4, the DKG contract adds node 2 to the QUAL set; similarly, if the DKG contract receives the confirmation of node 3 from node 1, node 2 and node 4, the DKG contract adds node 3 to the QUAL set; similarly, the DKG contract receives node 4 acknowledgements from node 1, node 2, and node 3, and the DKG contract adds node 4 to the QUAL set.

After the execution of the contract, the QUAL set comprises a node set of {1,2,3,4 }.

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

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

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

thus, for example, the public key share computed by consensus node 1 may be:

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

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

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

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

x_j＝∑_i∈QUALs_ijmod q equation (7)

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

the consensus node 2 locally computes its own private key share:

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

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

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

On the other hand, each consensus node may locally calculate a total public key based on the verification parameters and the node set in the contract, and the total public key may be calculated according to the following formula:

y＝∏_i∈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, that is, by the above method, each node obtains the same total public key.

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

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

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

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

s420, the first public identity node verifies each received secret share and the corresponding public verification parameter;

s430, after each verification is passed by the first contract node, the serial number of the node passing the verification is sent to a chain contract;

s440, the first common node receives the node set determined by the contract on the chain;

s450, the first consensus node calculates public key shares based on the verification parameters and the node set, and calculates corresponding private key shares based on the secret shares and the node set.

The first consensus node may also calculate an overall public key based on the authentication parameters and the set of nodes.

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

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

The method for receiving the public verification parameters by the first node through contract broadcasting on the chain comprises the following steps:

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

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

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

after collecting the commit messages of at least the number of quorum, the first consensus node verifies the signature shares in the received commit messages by adopting public key shares;

the first common identification node obtains a complete signature by passing the verified signature shares of at least the number of quorum through a recovery function corresponding to the private key shares generated by the threshold signature algorithm;

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

Wherein the unique values of the original transaction list include:

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

Wherein, the original message also comprises a block number and/or a time stamp.

Wherein, the original message further includes a random number seed or a block hash generated in a previous block.

Wherein still include:

the first common identification node puts the obtained random number seed into the block header of the generated current block.

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

each node generates public verification parameters corresponding to the own secret shares and broadcasts the public verification parameters through a chain contract;

after each common identification node passes each verification, the serial number of the verified node is sent to a contract on the chain;

Each consensus node may also compute the total public key locally based on the authentication parameters and the set of nodes.

The following description provides a first common node in a blockchain system, including

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

after each verification is passed by the first contract node, the serial number of the verified node is sent to the contract on the chain;

In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical blocks. For example, a Programmable Logic Device (PLD) (e.g., a Field Programmable Gate Array (FPGA)) is an integrated circuit whose Logic functions are determined by a user programming the Device. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to the software compiler used in program development, but the original code before compiling is also written in a specific Programming Language, which is called Hardware Description Language (HDL), and the HDL is not only one kind but many kinds, such as abel (advanced boot Expression Language), ahdl (alternate Language Description Language), communication, CUPL (computer universal Programming Language), HDCal (Java Hardware Description Language), langa, Lola, mylar, HDL, PALASM, rhydl (runtime Description Language), vhjhdul (Hardware Description Language), and vhygl-Language, which are currently used commonly. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using 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, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be regarded as a hardware component and the means for performing the various functions included therein may also be regarded as structures within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.

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

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

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

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

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

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

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

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

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

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

Claims

1. A method for distributed key generation over a blockchain, comprising:

each consensus node generates public verification parameters corresponding to the secret shares of the consensus node and broadcasts the public verification parameters through a chain contract;

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

after each common identification node passes each verification, sending the serial number of the verified node to the contract; the contract determines a node set according to the node numbers sent by the common nodes;

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

3. The method of claim 1, wherein each consensus node transmits n-1 of the generated n secret shares, respectively, to other n-1 nodes, including using P2P network components.

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

and each consensus node respectively sends n-1 secret shares in the generated n secret shares to other n-1 nodes after signing.

5. The method of claim 1, the broadcasting of the common authentication parameters via the on-chain contract, comprising:

broadcasting the common authentication parameters is achieved through an event mechanism of the blockchain.

6. The method of claim 1, each consensus node further calculates an overall public key based on a verification parameter and a set of nodes, respectively.

7. A method of implementing random number seed generation on a blockchain based on any of claims 1 to 6, comprising:

after collecting the commit messages with at least the number of quorum, each consensus node verifies the signature share in the received commit messages by adopting a public key share;

each common identification node obtains a complete signature by passing the verified signature shares with at least quorum number through a recovery function corresponding to the private key shares generated by the threshold signature algorithm;

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

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

10. The method of claim 7, wherein the original packet 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 current block being generated.

12. A method for distributed key generation over a blockchain, comprising:

the first node receives the node set determined by the contract on the chain;

13. The method of claim 12, the first node receiving the secret shares generated by the other nodes through a P2P network component.

14. The method of claim 12, the first node further signature verifies the received secret shares generated by the other nodes.

15. The method of claim 12, the first node receiving the corresponding common authentication parameters via a contract-on-chain broadcast, comprising:

16. The method of claim 12, each consensus node further calculates an overall public key locally based on authentication parameters and a set of nodes, respectively.

17. A method of implementing random number seed generation on a blockchain based on any of claims 12 to 16, comprising:

the first node obtains a complete signature by using the verified signature shares with at least quorum number through a reply method corresponding to the private key shares generated by the threshold signature algorithm;

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

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

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

20. The method of claim 17, wherein the original packet 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 puts the obtained random number seed into the block header of the generated current block.

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

the contract determines a node set according to the transaction sent by each consensus node;

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