WO2023185045A1

WO2023185045A1 - Method and system for generating random seed on blockchain, and consensus node

Info

Publication number: WO2023185045A1
Application number: PCT/CN2022/135233
Authority: WO
Inventors: 徐文博
Original assignee: 蚂蚁区块链科技(上海)有限公司
Priority date: 2022-03-29
Filing date: 2022-11-30
Publication date: 2023-10-05
Also published as: CN114726517A

Abstract

A method and system for generating a random seed on a blockchain, and a consensus node. The method comprises: in a Sign-share phase of SBFT-like consensus, each consensus node signs, by using a private key share of the consensus node, on the basis of a threshold signature algorithm, an original packet containing an original transaction list specific value in the consensus, to generate a signature share, and adds the signature share into a Sign-share message and sends the message to at least one collection node; after collecting at least a threshold number of Sign-share messages, the collection node applies a recovery function corresponding to the private key share generated by the threshold signature algorithm to at least the threshold number of the signature shares to obtain a complete signature; the collection node broadcasts a full-commit-proof message containing the complete signature to the consensus node; and each consensus node receiving the full-commit-proof message obtains a random seed on the basis of the complete signature in the full-commit-proof message.

Description

A method, system and consensus node for generating random number seeds on the blockchain

Technical field

The embodiments of this specification belong to the field of blockchain technology, and particularly relate to a method, system and consensus node for generating random number seeds on a blockchain.

Background technique

Blockchain is a new application model of computer technology such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm. In the blockchain system, data blocks are combined into a chained data structure in a chronological manner and are cryptographically guaranteed to be an untamperable and unforgeable distributed ledger. Due to the characteristics of blockchain, such as decentralization, non-tamperable information, and autonomy, blockchain has also received more and more attention and applications.

Contents of the invention

The purpose of this specification is to provide a method, system and consensus node for generating random number seeds on the blockchain.

A method of generating random number seeds on the blockchain, including: in the Sign-share phase of the SBFT-like consensus, each consensus node uses its own private key share pair to contain the unique value of the original transaction list in this consensus based on the threshold signature algorithm. Sign the original message, generate a signature share, and add the signature share to the Sign-share message and send it to at least one collection node; after the collection node collects at least a threshold number of Sign-share messages, at least a threshold number of them The number of signature shares passes the recovery function corresponding to the private key share generated by the threshold signature algorithm to obtain a complete signature; the collection node broadcasts a full-commit-proof message containing the complete signature to the consensus node; receiving the full-commit- Each consensus node of the proof message obtains a random number seed based on the complete signature.

A method of generating random number seeds on the blockchain, including: in the Pre-Commit/Commit voting stage of the Hotstuff-like consensus, each consensus node uses its own private key share pair to contain the original in this consensus based on the threshold signature algorithm. Sign the original message with the unique value of the transaction list, generate a signature share, and add the signature share to the broadcast message and send it to the collection node; after the collection node collects at least a threshold number of broadcast messages, at least a threshold number of them The signature share is obtained through the recovery function corresponding to the private key share generated by the threshold signature algorithm to obtain a complete signature, and a message containing the complete signature is broadcast to the consensus node; each consensus node that receives the broadcast message is based on the complete signature therein Get the random number seed.

A method of generating random number seeds on the blockchain, applied to a system including several consensus nodes and collection nodes, including: in the last round of voting before transaction execution, each consensus node uses its own private signature algorithm based on the threshold signature algorithm. The key share signs the original message containing the voting value in this consensus, generates a signature share, and sends the signature share to at least one collection node; the collection node will collect at least a threshold number of signature shares through the The recovery function corresponding to the private key share generated by the threshold signature algorithm obtains a complete signature; the collection node broadcasts the complete signature to the consensus node; each consensus node that receives the complete signature obtains a random number seed based on the complete signature.

The above scheme provided in this manual combines the threshold signature algorithm with the SBFT consensus algorithm, so that after the original transaction list corresponding to each block reaches consensus through the SBFT algorithm, the complete signature can be obtained through the adopted threshold signature algorithm, thus obtaining The random number seed can be used in the process of executing the transactions in the original transaction list corresponding to this block. In this way, no additional waiting is required to execute the transactions in this block.

The above solution provided in this manual is based on the nature of the threshold signature algorithm. Each consensus node generates the same random number seed based on a complete signature. Therefore, when each blockchain node executes the same transaction in the same block, for which The same random number generation process can generate the same random number based on the same random number seed to complete business logic such as lottery, red envelope issuing, blind box, or complete system contract/blockchain platform functions, and on each node Get consistent execution results.

In voting-based consensus algorithms, there is often a final round of voting. The messages in the last round of voting can be collected by a node, aggregated and then broadcast to other nodes, such as the commit message in Hotsguff and the Sign-share message in SBFT. The solution provided in this manual is applicable to the situation where there is a final round of voting in the consensus algorithm before executing the transaction, so as to reach a consensus on the transaction list to be executed and at the same time reach a consistent random number seed, which meets the requirements of consistency, immediacy, and impossibility. Predictable, uncontrollable and irrevocable.

Description of drawings

FIG. 1 is a schematic diagram of the conventional phase of a practical Byzantine fault-tolerant algorithm in an embodiment;

Figure 2 is a schematic diagram of the view switching stage of a practical Byzantine fault-tolerant algorithm in an embodiment;

Figure 3 is a schematic diagram of the normal phase of the practical Byzantine fault-tolerance algorithm in an embodiment when no consensus node is down;

Figure 4 is a flow chart for generating random number seeds on the blockchain in an embodiment of this specification;

Figure 5 is a schematic diagram of the block header structure in an embodiment of this specification;

Figure 6 is a flow chart for generating random number seeds on the blockchain in an embodiment of this specification;

Figure 7 is a flow chart of the SBFT algorithm in an embodiment of this specification;

Figure 8 is a flow chart of the HotStuff algorithm in an embodiment of this specification.

Detailed ways

In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of this specification. Obviously, the described The embodiments are only some of the embodiments of this specification, but not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by those of ordinary skill in the art without creative efforts should fall within the scope of protection of this specification.

The blockchain 1.0 era usually refers to the development stage of blockchain applications between 2009 and 2014. They are mainly dedicated to solving the decentralization problem of currency and payment methods. Since 2014, developers have increasingly focused on solving the technical and scalability deficiencies of the aforementioned solutions. At the end of 2013, Vitalik Buterin introduced smart contracts into the blockchain, opening up the application of blockchain beyond the currency field, thus opening the blockchain 2.0 era.

In the blockchain system, different participants can establish a distributed blockchain network through deployed nodes. A decentralized (or multi-centralized) distributed ledger constructed using a chain block structure is stored on each node (or on most nodes, such as consensus nodes) in the distributed blockchain network. Such a blockchain system needs to solve the problem of consistency and correctness of respective ledger data on multiple decentralized (or multi-centered) nodes. Each node (or multiple nodes) runs a blockchain program. Under the design of certain fault-tolerance requirements, the consensus mechanism is used to ensure that all loyal nodes have the same transactions, thereby ensuring that all loyal nodes have the same transactions. The execution results are consistent, and the transaction and execution results are packaged to generate blocks.

A smart contract is an automatically executed computer contract based on specified triggering rules. It can also be regarded as a digital version of a traditional contract. The concept of smart contracts was first proposed in 1994 by Nick Szabo, a cross-field legal scholar and cryptography researcher. This technology was once not used in actual industries due to the lack of programmable digital systems and related technologies, until the emergence of blockchain technology provided a reliable execution environment. Since blockchain technology uses a blockchain ledger, the data generated cannot be tampered with or deleted, and the entire ledger will continuously add ledger data, thus ensuring the traceability of historical data; at the same time, the decentralized operating mechanism avoids centralization influence of factors. Smart contracts based on blockchain technology can not only take advantage of smart contracts in terms of cost and efficiency, but also avoid malicious behavior from interfering with the normal execution of the contract. Smart contracts are written into the blockchain in digital form, and the characteristics of the blockchain technology ensure that the entire process of storage, reading, and execution is transparent, traceable, and cannot be tampered with.

Blockchain development and application diversification. Some business logic is edited into smart contracts and executed on the blockchain platform. Specifically, these smart contracts containing business logic can run on every node (or on most nodes, such as consensus nodes) in the blockchain network. Compared with the problem of single point of failure caused by the centralized business logic execution environment, which makes the entire centralized system unavailable, the execution of smart contracts in the blockchain environment is also called the "world computer". This is because of the distributed area. There are many nodes in the blockchain network that execute smart contracts independently. As mentioned before, smart contracts that execute the same logic on these different nodes need to obtain the same execution results to ensure that the ledgers saved by most of these nodes are consistent.

In some business logic, it may be necessary to generate a result based on random numbers, such as to implement the business logic of lottery, to implement the business logic of lottery, or to implement the business logic of issuing red envelopes or blind boxes with random amounts within a certain range. This generally needs to be done in a smart contract. Contains a program for generating random numbers. For another example, some system contracts may need to implement voting for master nodes or small-scale committees. This voting logic may use a random method or use random numbers. As mentioned before, a significant feature of the distributed blockchain network is that in order to ensure the overall availability of the distributed blockchain network, the ledgers in most nodes need to be consistent, which also requires intelligence in most nodes. The random numbers generated by the contract are consistent.

As mentioned above, each node (or multiple nodes) runs a blockchain program. Under the design of certain fault-tolerance requirements, the consensus mechanism ensures that all loyal nodes have the same transactions, thereby ensuring that all loyal nodes have the same transactions. The execution results are consistent, and the transactions and execution results are packaged to generate blocks. The current mainstream consensus mechanisms include: Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPOS), Practical Byzantine Fault Tolerance (PBFT) ) algorithm, Honey Badger Byzantine Fault Tolerance (HoneyBadgerBFT, also referred to as HBBFT) algorithm, etc.

Take PBFT as an example. This algorithm was proposed by Miguel Castro (Castro) and Barbara Liskov (Liskov) in 1999. It solved the problem of inefficiency of the original Byzantine fault-tolerant algorithm and reduced the algorithm complexity from exponential to The level is reduced to the polynomial level, making the Byzantine fault-tolerant algorithm feasible in practical system applications. The paper was published at the 1999 International Conference on Operating System Design and Implementation (OSDI99). In the PBFT algorithm, all replicas run in a rotation process (succession of configuration) called views. In a certain view, one replica serves as the primary node and the other replicas serve as 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 replica number, and |R| is the number of replica sets. It is assumed in this algorithm that when at most f replicas (i.e. nodes) fail, if the total number of replicas is at least 3f+1, security and liveness can be guaranteed in an asynchronous system. A set of a certain number of replicas required to ensure the data consistency and fault tolerance requirements of all replicas is generally a set composed of most nodes in a distributed system, forming a majority (Quorum). For example, when the total number of nodes n is 3f+1 (n=3f+2 or n=3f generally does not improve the fault tolerance effect), the Quorum is 2f+1. In this way, for a distributed system containing four nodes, any three nodes can form a Quorum.

PBFT includes two processes: Normal Case Phase and View Change Phase. Figure 1 is the flow chart of the Normal Case Phase (normal phase) process. Normal Case Phase mainly includes three stages: PRE-PREPARE (preparation), PREPARE (preparation) and COMMIT (commit). Node 3, for example, can represent a downed node (indicated by × in Figure 1). When the master node fails (indicated by × in Figure 2, for example, the master node Primary, that is, Replica 0 (replica 0) fails before changing the view), the view change process needs to be started to make adjustments when the system fails. Replace a new primary node (for example, Replica 1 is the primary node after changing the view). Figure 2 is a schematic diagram of View Change Phase. If the master node goes offline or does evil and does not broadcast the client's request, etc., the client can set a timeout mechanism. If the timeout occurs, the client can broadcast the request message to all replica nodes. After the replica node detects that the master node has done something evil or gone offline, it can also initiate the View Change protocol phase to replace the master node (often referred to as "switching the master"). In addition, it may also be due to the master node initiating an incorrect proposal that the three-phase consensus process of PRE-PREPARE, PREPARE and COMMIT may fail, or the PREPARE and COMMIT phases may not reach the number of Quorum (such as 2f+1 of 3f+1 nodes, Also known as a quorum), consensus cannot be achieved. In these cases, the View Change protocol phase may also be initiated to replace the master node.

Under normal circumstances, that is, the consensus nodes are not down, and the consensus message can reach the other party within a certain period of time, that is, when there is no change of owner, the Normal Case Phase process in PBFT can be shown in Figure 3. This figure Still taking 4 consensus nodes as an example.

In the Normal Case Phase process of the r-1 round, node 0 serves as the master node and collects a certain number of transactions to be agreed upon (or read and write sets, etc., which will be explained later using transactions as examples), and then initiates the pre-preparation process (i.e. the aforementioned PRE-PREPARE, also referred to as the PP phase), and then

nodes

1, 2, and 3 enter the preparation process (the aforementioned PREPARE, also referred to as the P phase), and then

nodes

0, 1, 2, and 3 enter the submission process (the aforementioned COMMIT, also referred to as phase C). The PP stage, P stage, and C stage are generally collectively referred to as the three stages of PBFT. In this way, under normal circumstances, the three-stage process of the r-1 round of PBFT is completed, and the consensus of the transaction data corresponding to the m-1 block is completed, and the block number of this block is also generated. information. Therefore, each consensus node can execute these transactions sequentially based on the consensus transaction data and in accordance with the order and content of the consensus transaction data, thereby generating world status and receipts. Specifically, each node can build a Merkle tree (including tree structures such as MPT trees) based on local consensus transaction data. MPT is called Merkle Patricia Tree, which is a combination of Merkle Tree (Merkle Tree) and Patricia Tree (compression prefix). tree, a more space-saving Trie tree, a tree structure of a dictionary tree) and generates the hash of the root of this Merkle tree (also called the transaction root hash). Similarly, it can be constructed based on world state data Merkle tree and generate the hash of the root of the Merkle tree (also called the state root hash). You can build the Merkle tree based on the receipt data and generate the hash of the root of the Merkle tree (also called the receipt root hash). After each node generates these three root hashes locally, it can generate the m-1th block locally. The block header of the m-1th block may include the aforementioned block number, transaction root hash, status root hash, receipt root hash and other information. The block body may include a transaction data set, a world state set and a receipt set. In this way, the m-1th block is generated.

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

nodes

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

nodes

0, 1, 2, 3 Enter the C process. In this way, under normal circumstances, the three-stage process of the r-th round of PBFT is completed, and the consensus of the transaction data corresponding to the m-th block is completed. At the same time, the block number and other information of this block are also generated. Each node can execute these transactions sequentially based on the consensus transaction data and in accordance with the order and content of the consensus transaction data, thereby generating world status and receipts. After each node generates the three root hashes locally, it can generate the m-th block locally. The block header of the m-th block may include the aforementioned block number, transaction root hash, status root hash, receipt root hash and other information. The block body may include a transaction data set, a world state set and a receipt set. In this way, the m-th block is generated. Similarly, the m+1th block is generated, and this process includes the three-stage process of the r+1th round of PBFT as shown in Figure 3.

It can be seen that in the case of regular block generation, each consensus node includes a Normal Case Phase process of PBFT in the generation process of each block. As blocks continue to be generated, each consensus node will repeat this consensus process. Figure 3 only illustrates the r-1, r, and r+1 rounds of consensus processes. Among them, some consensus nodes serve as the main node in PBFT, and some consensus nodes serve as the backup node in PBFT.

In a consensus process, that is, a three-stage process of PBFT, it can include: a110: (PRE-PREPARE preparatory phase) After master node 0 collects a certain number of transactions to be agreed upon, it sorts and packages the transactions to be agreed into messages m (also called the original transaction list), send pre-prepare requests to

backup nodes

1, 2, and 3. The pre-prepare requests include message m; a120: (PREPARE preparation phase)

Nodes

1, 2, and 3 receive pre-prepare After the request, if the message m is checked to be legal, the hash value of the received message m will be broadcast through the prepare message (the content of the broadcast generally does not include the message m itself, because the message m includes several original transaction requests, and the volume is generally relatively large. ). Specifically, node 1 diffuses the prepare message to

nodes

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

nodes

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

nodes

0, 1, and 2. Correspondingly, each node also receives prepare messages broadcast by other nodes. Each node adds the prepare message it sends (which contains the hash value of message m, representing its own approval) and the prepared message it receives (which contains the hash value of message m, which represents the approval of other nodes) to the local log ( Log). If a node collects at least Quorum number of legal pp messages/p messages from different nodes (including pre-prepare, prepare messages sent by itself, and prepare messages received), it changes to the prepared state.

a130: (COMMIT submission phase) After entering the prepared state, each node participating in the consensus sends a commit message to other consensus nodes, and adds the commit message it sends to the local Log (representing its own approval), and , each node also receives commit messages broadcast by other nodes. If a node collects legal commit messages of at least Quorum from different nodes and adds them to the local Log (plus the total Quorum it added to the local Log), it changes to the committed state.

a140: The node that changes to the committed state outputs message m as the consensus result of this round.

Which transactions are included in the message m, and the order of the included transactions, are generally determined by the master node in a110. Determining which transactions are included and the sequence of included transactions are two important aspects of the consensus mechanism. The blockchain network may receive many transaction requests. Which transactions are packaged by the master node in a110 determines which transactions will be processed by the blockchain network, and the execution results of the transactions will be uploaded to the chain. Even for the same set of transactions, different execution sequences will lead to different final results, which affects whether the ledgers on each node are consistent.

This specification provides a method for generating random number seeds on the blockchain, which can be implemented in conjunction with the above three-stage PBFT process. As shown in Figure 4, it includes: S110: In the commit phase of PBFT, each consensus node uses its own private key share to sign the original message containing the unique value of the original transaction list in this consensus based on the threshold signature algorithm, and generates a signature. share and add the signed share to the broadcast commit message.

Threshold signature is an important branch of ordinary digital signature and a combination of threshold secret sharing technology and digital signature. The traditional signature scheme can be implemented using the RSA algorithm. The RSA algorithm is an asymmetric encryption algorithm jointly proposed by Ron Rivest, Adi Shamir and Leonard Adleman in 1977. The RSA algorithm can complete decryption without directly transmitting the key, which can ensure the security of the information and avoid the risk of information being cracked caused by directly transmitting the key. RSA includes a private key and a public key, and the private key and public key are in pairs. After a piece of information is encrypted by a public key, it can only be decrypted by the corresponding private key; similarly, after a piece of information is encrypted by a private key, it can only be decrypted by the corresponding public key. The reason for this property is that there is a correlation between pairs of private keys and public keys in mathematical principles. For example, an underlying principle is that according to number theory, it is relatively simple to find two large prime numbers, and their product is Factoring is extremely difficult, so security can be guaranteed by exposing the product as an encryption key. The private key is usually kept strictly confidential and cannot be leaked, while the public key is public (and can be held by multiple people). Since the private key is kept strictly confidential by the holder, others cannot forge the signature of the private key holder without obtaining the private key.

The RSA signature mechanism can ensure the integrity of the message delivery process. For example, node A needs to transmit a message to node B, and it may be transited by several nodes in the process. Then A can use the RSA signature mechanism to transmit the message together with the signature to B through several intermediate nodes, and B's verification of the signature can confirm that the received message was sent by A and has not been tampered with during the transmission process. . The process of an RSA signature is as follows: b1: A generates a pair of keys (public key and private key). The private key is not made public and is kept by itself. The public key is public and can be obtained by anyone.

b2: A signs the hash value of the original message with its own private key, and passes the original message and the signature result to B together. As mentioned before, this delivery process may be forwarded by several intermediate nodes.

The hash algorithm, also known as the hash algorithm, can map the original content into a fixed-length sequence, and this sequence is the hash value. Generally, there are hash algorithms such as sha256, sha384, and sha512. The result of sha256 is 256 bits, which can represent 2 to the 256th power of the original content. Similarly, the result of sha384 is 384bits, and the result of sha512 is 512bits. These hash algorithms can target original content with more content and larger volume, so the hash value can be relatively smaller than the original content. A good hash algorithm can ensure that different original contents are mapped to different hash values with a high probability. At the same time, this mapping is messy, that is, it is impossible to predict the correlation of hash values obtained from different original contents; and it is also resistant to inverse operations. That is, the original content cannot be obtained from the hash value.

The original message may have a lot of content and be large in size. Using the private key to directly calculate the signature of the original message may be time-consuming and computationally intensive. Therefore, the original message can be calculated into a hash value using a hash algorithm, so that the hash value is smaller in length and can completely represent the original message. Then, the hash value is encrypted and calculated using the private key, and the result is the signature.

b3: After receiving the message, B uses A’s public key to verify the signature.

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

The threshold signature scheme first includes 1 total public key and n public-private key pairs. One public key in each public-private key pair is called a public key share, and one private key in each public-private key pair is called a private key share. Secondly, there is a recovery function corresponding to this total public key and n public-private key pairs. This recovery function can restore the signature shares of at least a threshold number of different private key share signatures into a complete signature. This generated complete signature can also be The total public key mentioned above is used to verify the correctness. Any signature share less than the threshold number cannot restore the complete signature.

In addition to the threshold signature mechanism based on RSA, you can also use the threshold signature mechanism based on ECDSA (Elliptic Curve Digital Signature Algorithm, Elliptic Curve Digital Signature Algorithm), based on Schnorr (a knowledge proof mechanism based on discrete logarithm problems) Threshold signature mechanism, threshold signature mechanism based on BLS (Boneh-Lynn-Shacham Signature), etc.

It should be noted that for the threshold signature used in the blockchain, the number of private key shares can be equal to the number of consensus nodes, and the minimum number of signature shares (ie, the threshold number) required by the recovery function to generate a complete signature can be equal to PBFT. quorum in algorithms. Of course, the number of private keys may not be equal to the number of consensus nodes, and the number of minimum signature shares required by the recovery function to generate a complete signature may not be equal to the quorum in the PBFT algorithm. The following uses the former as an example.

The 1 total public key and n public-private key pairs can be generated by a centralized dealer and distributed to n blockchain consensus nodes. This is a centralized key distribution method. In this way, combined with the consensus algorithm, n private key shares can be held by each blockchain consensus node. At the same time, each blockchain consensus node can hold the same 1 total public key. In addition, there is a decentralized key distribution method, that is, the dealer is cancelled, but n consensus nodes negotiate to obtain n public-private key pairs and 1 total public key through the key agreement process. Each consensus node is still independent Holds one of n private key shares, and each consensus node holds the same total public key.

Using the threshold signature algorithm, each consensus node can use its own unique private key (for example, in a blockchain network containing 4 nodes and using PBFT as the consensus algorithm, node 0, node 1, node 2, node 3 The private key shares held by the threshold signature algorithm are sk0, sk1, sk2, sk3 respectively (the subscript number can represent the node number) to sign the original message containing the unique value of the original transaction list in this consensus, and obtain the signature result. Here, the unique value of the original transaction list can be used as the original message for the signature.

The unique value of the original transaction list can include the original transaction list itself or the hash value of the original transaction list. Generally speaking, different transactions have different transaction contents, so different original transaction lists or their hash values are generally different. Therefore, the original message can at least include the original transaction list or its hash value, so that the properties of the hash function are enough to distinguish the random number seeds generated after the completion of the consensus process corresponding to different blocks.

Considering that a number will be generated for the content of this consensus during the consensus process, if the consensus is completed, the generated number can be used as the block number of the block corresponding to this consensus. Therefore, the block number (that is, the number) can also be as the content in the original message. Regardless of whether the original transaction list contained in the N+1th block is the same as the original transaction list contained in the Nth block, block generation is sequential, which can be reflected as the block number of the latter block is The block number of the previous block +1. Therefore, the block number is used as the content in the original message. Even if the original transaction list contained in the N+1th block is the same as the original transaction list contained in the Nth block, each node still uses its own private transaction list. The key gets different signatures based on (original transaction list + block number). The master node still cannot match the signatures of other nodes, so it is impossible to predict the complete signature of the N+1 block, so the master node cannot use the N+1 block. The public random number seed is used to predict the random number seed of block N+1, achieving the purpose of being unpredictable. Similar to the number, the timestamp is also unique to a block, and the timestamp of the next block is after the previous block. Therefore, the timestamp can also be used as the content in the original message.

In addition to the unique values of the original transaction list, the signed object can also add other content, such as the random number seed generated in the previous block, that is, the original message can also include the random number seed generated in the previous block. After the aforementioned a140 is executed, as mentioned above, each node can generate the m-th block based on the consensus transaction data. Since the m-th block is independently generated locally by each node, if the blockchain nodes do not broadcast the hash value of the previous block they generated to each other and compare it, each node may not be able to determine the block. Whether the m-th block generated in the chain network is the same, or whether the m-th block generated on at least a quorum number of consensus nodes is the same from the perspective of the overall availability of the blockchain system. After the random number seed generation process in this manual, the random number seeds in the same block should be the same, and the random number seeds in different blocks should be different, so the random number seeds can be added to the original message. In this way, if the random number seeds corresponding to the m-th block generated by each node are different, depending on the nature of the threshold signature algorithm, it may not be possible to pass the recovery function in the process of generating the random number seeds for the m+1-th block. The method obtains a complete signature, which can help the consensus node confirm whether the previous block is consistent according to the scheme of this manual. The hash value of the previous block can also be used to replace the random number seed of the previous block. Since the hash value of a block is generally unique, it can also help the consensus node confirm whether the previous block is consistent.

Use your own private key share to sign the original message containing the unique value of the original transaction list in this consensus. The unique value of the original transaction list that can be included in this original message can be the original transaction list. Generally, the original transaction list has been broadcast in the PP phase of PBFT, and if the commit message broadcast in the C phase is smaller, it is more conducive to dissemination and bandwidth saving, so the unique value of the original transaction list can be the hash value of the original transaction list.

If the original message contains multiple contents, such as the original transaction list hash value, block number, and random number seed generated in the previous block, you can first calculate the hash value of the original message and then use the private key share Sign the hash value of the original message to obtain the signature result.

Sign the original message, and the generated signature result and the original message can be added to the broadcast commit message. In this way, during the commit phase, each node participating in the consensus sends a commit message to other consensus nodes, and adds the commit message it sends to the local Log (representing its own approval), and each node also receives Commit messages broadcast by other nodes.

S120: After each consensus node collects at least a threshold number of commit messages, the signature share of at least the threshold number is obtained through the recovery method corresponding to the private key share generated by the threshold signature algorithm to obtain a complete signature.

As mentioned before, in application, the threshold signature algorithm can generate 1 total public key and n public-private key pairs, and can generate recovery functions corresponding to the n public-private key pairs. As mentioned above, this recovery function can recover at least a threshold number of signatures that have been verified correctly to generate a complete signature. The threshold value of the threshold signature algorithm, that is, the threshold number can be set to w. Of course, when there are more than w correct signatures, a complete signature can also be generated through this recovery function. That is to say, when the number of correct signatures is greater than or equal to the threshold number w, a complete signature can be generated through the recovery function, and the complete signature generated is certain and will not change due to the number of correct signatures entered (as long as Greater than or equal to w).

The complete signature generated can be verified for correctness by the total public key. In this way, any node or other device holding the total public key can use the total public key to verify the correctness of the complete signature. For example, after node 1 generates a complete signature, the total public key can be used to verify the integrity of the complete signature. For example, the total public key can be used to perform cryptographic operations on the complete signature to obtain the first hash, and the original message can be hashed to obtain the second hash. hash, if the first hash is consistent with the second hash, the integrity of the complete signature can 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 node 1 generates a complete signature, it can send the complete signature, the total public key and the original message to a device outside the blockchain, and the device can use the total public key and the original message to verify the complete signature. The correctness of the principle is the same as above and will not be repeated. The original text of the message here is still the aforementioned content that contains the unique value of the original transaction list in this consensus, or it also includes the block number and/or timestamp of the current block and/or the random number seed generated in the previous block. .

In addition, each consensus node may collect each commit message, use the corresponding public key share to verify the signature share in the received commit message, and then pass at least a threshold number of signature shares through all The recovery function corresponding to the private key share generated by the threshold signature algorithm obtains a complete signature. Compared with the method of using the total public key to verify the complete signature generated, the method of using the public key share to verify each signature share, and then restoring it to the complete signature through the recovery function after passing the verification, can determine which signature is wrong. This way it can be determined which node may be the evil node.

In the threshold signature algorithm, each consensus node has 1 total public key and 1 private key share among n public-private key pairs and the corresponding 1 public key share. As mentioned above, it can be generated and distributed by the dealer. , or it can be obtained through negotiation among the consensus nodes.

Each consensus node can use the corresponding public key share to verify the signature share in the received commit message. Specifically, for example, in a consortium chain using the PBFT consensus algorithm containing 4 consensus nodes, node 0 broadcasts the signature share σ _3,0 generated by itself to

nodes

1, 2, and 3 in S110, where σ _3,0 is Mark 3 can represent the block number, and 0 can represent that this is the signature share of node 0; in S120, node 0 also receives the signature shares σ _3,1 and σ _3,2 broadcast by

nodes

1 and 2 respectively. In this way, node 0 has collected at least 3 signature shares, including the signature share σ _3,0 broadcast by itself and the signature shares σ _3,1 and σ _{3,2 broadcast by nodes 1 and 2} . Of course, node 0 can also collect all the signature shares σ _3,0 , σ _3,1 , σ _3,2 and σ _3,3 , which of course satisfies at least the quorum number.

Furthermore, node 0 can use the corresponding public key share to verify the collected σ _3,0 , σ _3,1 , σ _3,2 or also include σ _3,3 (or σ _3,0 , σ _3,1 , σ _3,3 or also includes σ _3,2 , or σ _3,1 , σ _3,2 , σ _3,3 or also includes σ _3,0 , or σ _3,0 , σ _3,2 , σ _{3, 3} or also includes the correctness of σ _3,1 ). Specifically, for example, node 0 can use the corresponding public key share to calculate the signature share σ _3,1 , and obtain a hash value, recorded as hash _3,1 ; node 0 can also perform the same hash calculation on the original message. Get hash′ _3,1 . If hash _3,1 is equal to hash′ _3,1 , it can be proved that the original message was sent by node 1 and has not been tampered with during the transmission process. In this way, the correctness of σ _3,1 is verified. Similarly, node 0 can verify σ _{3, 2} , etc., which will not be described again.

Similarly, node 1 can use the corresponding public key share to verify the collected σ _3,0 , σ _3,1 , σ _3,2 or also include σ _3,3 (or σ _3,0 , σ _3,1 , σ _3,3 or also includes σ _3,2 , or σ _3,1 , σ _3,2 , σ _3,3 or also includes σ _3,0 , or σ _3,0 , σ _3,2 , σ _{3 ,3} or also includes the correctness of σ _3,1 ).

Similarly, node 2 can use the corresponding public key share to verify the collected σ _3,0 , σ _3,1 , σ _3,2 or also include σ _3,3 (or σ _3,0 , σ _3,1 , σ _3,3 or also includes σ _3,2 , or σ _3,1 , σ _3,2 , σ _3,3 or also includes σ _3,0 , or σ _3,0 , σ _3,2 , σ _{3 ,3} or also includes the correctness of σ _3,1 ).

Similarly, node 3 can use the corresponding public key share to verify the collected σ _3,0 , σ _3,1 , σ _3,2 or also include σ _3,3 (or σ _3,0 , σ _3,1 , σ _3,3 or also includes σ _3,2 , or σ _3,1 , σ _3,2 , σ _3,3 or also includes σ _3,0 , or σ _3,0 , σ _3,2 , σ _{3 ,3} or also includes the correctness of σ _3,1 ).

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

Random seed refers to the initial value used to generate pseudo-random numbers in a pseudo-random number generator. For a pseudo-random number generator, starting from the same random number seed, the same random number sequence can be obtained. For a single machine, the random number seed can be determined by the current status of the computer, such as the current time. For distributed systems, the same random number seed must be generated on each node to generate the same random number based on the same random number seed in system contracts/business contracts/blockchain platform functions, etc., and should not Random numbers are generated by any node in a controllable, predictable, and revocable manner. This needs to be determined jointly by the nodes participating in the consensus. Moreover, considering that distributed networks are often asynchronous networks or semi-synchronous networks, from the perspective of immediacy, random numbers need to be generated and used when the transactions in the current block are executed.

After the above steps S110-S120, under normal circumstances each consensus node can obtain the same complete signature. Of course, considering the fault-tolerant nature of the distributed system, there should be at least a quorum of consensus nodes in a blockchain network using the PBFT consensus algorithm, each of which can obtain the same complete signature.

In this way, based on the complete signature, each consensus node can use the same random number seed generation algorithm to generate random number seeds. A relatively simple random number seed generation algorithm is, for example, the sha256 algorithm. Of course, you can also directly use the complete signature as a random number seed.

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

In this way, in the process of the blockchain node outputting the consensus result after executing the current consensus, that is, in the process of executing a series of transactions with determined content and sequence, if it contains smart contracts/system contracts/blocks that require the use of random numbers, The chain platform code can be executed based on the random number seed of S130. For example, in a smart contract written in C++ language, the mt19937(r) method provided by the C++ standard library or the boost library can be used to construct a cross-platform consistent random number engine, where the parameter r is the random number seed. Similarly, the random library in python and the random library in java also provide similar random number generation methods. Based on the same random number seed, the same random number can be generated under the same random number generation algorithm. In this way, for example, when each blockchain node executes the same transaction in the same block, the same random number generation process can generate the same random number based on the same random number seed, thereby completing tasks such as lottery, red envelope issuing, blind business logic such as boxes, or complete system contract/blockchain platform functions, and obtain consistent execution results on each node.

In addition, based on the above solution, the following steps may also be included: S140: Each consensus node puts the obtained random number seed into the block header of the current block generated.

Figure 4 is a schematic structural diagram of a block header. In the structure shown in Figure 5, the block header of each block includes several fields, such as the previous block hash previous_Hash (Prev Hash in the figure), Nonce (this is the random number involved in the workload proof, and this The random number seeds in the instructions are different, and this nonce is not enabled in some alliance chains), timestamp Timestamp, previous block number Block Num, state root hash State Root, transaction root hash Transaction Root, receipt root hash Hope Receipt Root et al. Among them, the Prev Hash in the block header of the next block (such as block N+1) points to the previous block (such as block N), which is the hash value of the previous block, that is, the hash value of the previous block. The hash value of the block header. The hash value of the block header can be the hash value calculated by a certain hash algorithm after sequentially splicing the fields contained in the block header. In this way, the next block locks the previous block through the block header on the blockchain. In particular, as mentioned above, state root is the hash value of the root of the MPT tree composed of the status of all accounts in the current block, and the point pointing to state_root is a state trie in the form of MPT. Transaction Root is generally the hash value of the tree root node after the original transaction list contained in this block is organized into a tree structure. Receipt Root is generally all the receipts generated after the transactions included in this block are executed, organized into a tree structure. The hash value of the tree root node after the structure.

It should be noted here that this instruction can add a field in the block header - "random number seed", which is the random number seed in S130. In this way, the random number seed generated in this block can be recorded on the blockchain ledger. In addition, for the playback block, the transactions involving random numbers in the block can be played back according to the random number seed in the block header.

The above scheme provided in this manual combines the threshold signature algorithm with the PBFT consensus algorithm, so that after the original transaction list corresponding to each block reaches consensus through the PBFT algorithm, the complete signature can be obtained through the adopted threshold signature algorithm, thus obtaining The random number seed can be used in the process of executing the transactions in the original transaction list corresponding to this block. In this way, no additional waiting is required to execute the transactions in this block.

The above scheme provided in this manual is based on the nature of the threshold signature algorithm. Each consensus node can recover the same complete signature through the recovery function based on at least a threshold number of signature shares, and then generate the same random number seed. Therefore, each block When the chain nodes each execute the same transaction in the same block, the same random number generation process can generate the same random number based on the same random number seed, thereby completing business logic such as lottery, red envelope issuance, and blind box. Or complete the system contract/blockchain platform functions and obtain consistent execution results on each node.

The above solution provided in this manual combines the threshold signature algorithm with the PBFT consensus algorithm, making it impossible for any consensus node to predict the complete signature before the consensus is completed. Even the master node of PBFT cannot predict the complete signature, and therefore cannot predict the random number. Seeds and random numbers. Especially when the threshold = quorum, once the consensus is completed, since the quorum number of nodes have reached an agreement on the content and order of the transaction list, that is, the basic content of generating a new block has been determined, at this time, at least the quorum number of nodes obtained according to the recovery function The complete signatures are the same, and the random number seeds generated by this quorum number of nodes must also be the same. Even if no more than f nodes do evil and want to control or revoke the random number seeds obtained, these f nodes will not affect the system. Consistency means that these f nodes cannot manipulate or revoke the generated complete signature, random number seed and random number.

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

In fact, in voting-based consensus algorithms, there is often a final round of voting, which can be broadcast directly to each other or through gossip protocols, such as commit messages in PBFT, pre-commit messages in Tendermint, and user messages in HoneyBadger. Messages decrypted at thresholds, etc. The solution provided in this manual is applicable to the situation where there is a final round of voting in the consensus algorithm before executing the transaction, so as to reach a consensus on the transaction list to be executed and at the same time reach a consistent random number seed, which meets the requirements of consistency, immediacy, and impossibility. Predictable, uncontrollable and irrevocable.

The following describes a method of generating random number seeds on the blockchain from the perspective of a consensus node in the blockchain network in a blockchain network that first agrees on the transaction list and then executes the transactions in the consensus transaction list, and In the consensus algorithm adopted, consensus results are output by broadcasting messages to each other in the last stage. The consensus node executes the content as shown in Figure 6: S210: The consensus node uses its own private key share to process the original message based on the threshold signature algorithm. Sign, generate a signature share, and add the signature share to the broadcast message.

In addition to PBFT outputting consensus results by mutually broadcasting submission proposals in the final stage, there are also some consensus algorithms that can also output consensus results by mutually broadcasting submission proposals in the final stage. The latter are, for example, Chinese patents ZL202111175184.1 and ZL202111178795.1 , ZL202111178745.3, ZL202111178754.2, ZL202111175144.7, ZL202111175151.7 and Chinese patent application CN202111178779.2.

Using the threshold signature algorithm, the consensus node can use its own unique private key share to sign the original message containing the unique value of the original transaction list in this consensus to obtain the signature result. Here, the unique value of the original transaction list can be used as the original message for the signature.

The unique value of the original transaction list can include the original transaction list itself or the hash value of the original transaction list. The block number (that is, the number) and/or the timestamp can also be used as the content of the original message. In addition to the unique values of the original transaction list, the signed object can also add other content, such as the random number seed generated in the previous block, that is, the original list can also include the random number seed generated in the previous block, so that The solution in this manual can be used to help the consensus node confirm whether the previous block is consistent.

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

Each consensus node can use the corresponding public key share to verify the signature share in the received commit message. Specifically, for example, in a consortium chain that uses the PBFT consensus algorithm and contains 4 consensus nodes, node 0 broadcasts the signature share σ _3,0 generated by itself to

nodes

1, 2, and 3 in S210, where the lower part of σ _3,0 Mark 3 can represent the block number, and 0 can represent that this is the signature share of node 0; in S220, node 0 also receives the signature shares σ _3,1 and σ _3,2 broadcast by

nodes

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

After the above steps S210-S220, the consensus node can obtain a complete signature under normal circumstances. In this way, based on the complete signature, the consensus node can use a random number seed generation algorithm to generate a random number seed. A relatively simple random number seed generation algorithm is, for example, the sha256 algorithm. Of course, you can also directly use the complete signature as a random number seed.

After the above process, a random number seed can be generated on the local blockchain of the consensus node. The above process can be applied to the last stage of PBFT (commit message broadcast and interaction in the submission stage), or to the Aux message in the BA (Binary Agreement) stage of HBBFT. Broadcasting and interaction can also be message broadcasting and interaction in the threshold decryption stage using the threshold encryption algorithm), or pre-commit message broadcasting and interaction applicable to Tendermint.

This specification also provides a method for generating a block header. Based on the above S210-S230 method, it may also include: the consensus node puts the obtained random number seed into the generated block header of the current block.

This specification also provides a method for generating random numbers on the blockchain. Based on the above S210-S230 method, it may also include: the consensus node generates random numbers based on the generated random number seeds.

The above introduces the implementation process of this manual using the three stages of PBFT as an example. Various consensus algorithms, typically PBFT (and HBBFT), use the many-to-all (all-to-all) message mode to submit a confirmation block. In this many-to-many messaging model, the number of interactive messages will grow exponentially as the network scale grows.

Therefore, this type of many-to-many message interaction has poor scalability and is difficult to apply to large-scale network nodes.

On the basis of PBFT, the SBFT consensus algorithm was subsequently evolved to solve the scalability problem. SBFT uses the view change protocol like PBFT. Each view has one replica as primary, and other replicas as backups. Unlike PBFT, these backups can also have other identities, commit collector (c-collector) and execution collector (execution collector, e-collector). SBFT includes two modes, namely fast path and Linear-PBFT. Fast path is the default execution mode. When fast path cannot reach consensus, Linear-PBFT is used. As shown in Figure 6, through this collector communication mode, SBFT no longer sends the message to each replica, but to the collector, which then broadcasts it to all replicas. In each view, there can be c+1 c-collectors and c+1 e-collectors to collect and combine threshold signatures and propagation result signatures respectively.

The entire system has (3f+2c+1) nodes (ie Replicas), numbered from 1 to (3f+2c+1).

SBFT uses threshold signatures. For n replicas, only a subset of replicas needs to sign the transaction set to verify. The replicas in the subset are signed with their own private keys and sent to a recipient. Threshold signatures are divided into three groups.

The signature of the first group is set to σ, and the signature threshold can be set to (3f+c+1).

The signature of the second group is set to π, and the signature threshold can be set to (f+1).

As shown in Figure 7, the SBFT process is as follows: Request: The client (c in the figure) initiates a transaction request to the primary node (Primary). Here is the process of a client initiating a transaction request. In fact, there can be multiple transaction requests, and the multiple transaction requests can be initiated to the Primary by one or more different clients. Each transaction request can be sent directly to the Primary or forwarded to the Primary through other nodes.

Pre-prepare phase (Pre-prepare): After the Primary collects a certain amount of transaction requests, it sorts these transaction requests, packages them into a transaction list and places them in a pre-prepare message (pre-prepare message), and broadcasts the pre-prepare message to other parties. Replicas.

Signature share stage (Sign-share): Each Replica signs the pre-prepare message with its own private key share in the first group, generates a signature share, and sends a Sign-share message containing the signature share to each C- Collector (1 C-Collector in the picture).

Full-commit-Proof: Each C-Collector collects at least the first threshold signature shares of the first group and recovers the first complete signature σ, and broadcasts a full commit containing the first complete signature σ. Prove (full-commit-proof) to Replicas.

Sign-state phase (Sign-state): Each time a full-commit-proof Replica is received, the first set of total public keys can be used to verify the first complete signature σ. After the verification is passed, the transaction list can be submitted and executed sequentially. transaction, and use the private key share in the second group to sign the execution result (generally the state set after execution, which can be represented by the hash value of the root node after the state set is organized into a tree structure) to generate a signature state , and then send the signature status to each E-Collector.

Full-execute-proof phase: Each E-Collector collects at least the second threshold signature share of the second group and recovers the second complete signature π, and broadcasts the full-execute proof containing the complete signature π ( full-execute-proof) to Replicas.

After receiving the full-execute-proof Replica, the second complete signature π can be verified through the total public key of the second group.

Execution confirmation (Execute-ack): Any E-Collector can also send an execution confirmation (execute-ack) message to the requesting client.

In addition, if the client times out, the request can be resent to all Replicas.

Since these two nodes, c-collectors and e-collectors, collect and combine threshold signatures and propagation result signatures respectively, they can be called collection nodes.

Compared with PBFT, SBFT only needs to send 1/3 of its number of messages and reaches consensus faster.

Based on the above-mentioned SBFT process, this specification provides a method for generating random number seeds on the blockchain, as shown in Figure 7, including: S310: In the Sign-share stage of SBFT, each consensus node uses the threshold signature algorithm. The own private key share signs the original message containing the unique value of the original transaction list in this consensus, generates a signature share, and adds the signature share to the Sign-share message and sends it to at least one collection node.

As mentioned before, the threshold signature scheme first includes 1 total public key and n public-private key pairs. One public key in each public-private key pair is called a public key share, and one private key in each public-private key pair is called a private key share. Secondly, there is a recovery function corresponding to this total public key and n public-private key pairs. This recovery function can restore the signature shares of at least a threshold number of different private key share signatures into a complete signature. This generated complete signature can also be The total public key mentioned above is used to verify the correctness. Any signature share less than the threshold number cannot restore the complete signature.

The threshold signature mechanism can use threshold signature algorithms based on BLS, RSA, ECDSA, Schnorr, Boneh-Lynn-Shacham Signature, etc.

Using the threshold signature algorithm, each consensus node can use its own unique private key (for example, in a blockchain network containing 4 nodes and using SBFT as the consensus algorithm, node 1, node 2, node 3, node 4 The private key shares held by the threshold signature algorithm are sk1, sk2, sk3, sk4 respectively (the subscript number can represent the node number) to sign the original message containing the unique value of the original transaction list in this consensus, and obtain the signature result. Here, the unique value of the original transaction list can be used as the original message for the signature.

In addition to the unique values of the original transaction list, the signed object can also add other content, such as the random number seed generated in the previous block, that is, the original message can also include the random number seed generated in the previous block. As mentioned before, each node can generate the m-th block based on the consensus transaction data. Since the m-th block is independently generated locally by each node, if the blockchain nodes do not broadcast the hash value of the previous block they generated to each other and compare it, each node may not be able to determine the block. Whether the m-th block generated in the chain network is the same, or whether the m-th block generated on at least a quorum number of consensus nodes is the same from the perspective of the overall availability of the blockchain system. After the random number seed generation process in this manual, the random number seeds in the same block should be the same, and the random number seeds in different blocks should be different, so the random number seeds can be added to the original message. In this way, if the random number seeds corresponding to the m-th block generated by each node are different, depending on the nature of the threshold signature algorithm, it may not be possible to pass the recovery function in the process of generating the random number seeds for the m+1-th block. The method obtains a complete signature, which can help the consensus node confirm whether the previous block is consistent according to the scheme of this manual. The hash value of the previous block can also be used to replace the random number seed of the previous block. Since the hash value of a block is generally unique, it can also help the consensus node confirm whether the previous block is consistent.

Use your own private key share to sign the original message containing the unique value of the original transaction list in this consensus. The unique value of the original transaction list that can be included in this original message can be the original transaction list. Generally, the original transaction list has been broadcast in the Pre-Prepare phase of SBFT, and if the commit message broadcast in the Sign-share phase is smaller, it is more conducive to dissemination and bandwidth saving, so the unique value of the original transaction list can be the hash value of the original transaction list.

If the original message contains multiple contents, such as the original transaction list hash value, block number, and random number seed generated in the previous block, you can first calculate the hash value of the original message and then use the private key share Sign the hash value of the original message to obtain the signature share.

Sign the original message, and the generated signature share and the original message can be added to the Sign-share message. In this way, during the Sign-share phase, each of the nodes participating in the consensus sends a Sign-share message to the collection node.

S320: After collecting at least a threshold number of Sign-share messages, the collection node passes at least a threshold number of signature shares among them through the recovery function corresponding to the private key share generated by the threshold signature algorithm to obtain a complete signature.

In addition, the collection node may also collect each Sign-share message, use the corresponding public key share to verify the signature shares in the received Sign-share message, and then add at least a threshold number of signature shares A complete signature is obtained through the recovery function corresponding to the private key share generated by the threshold signature algorithm. Compared with the method of using the total public key to verify the complete signature generated, the method of using the public key share to verify each signature share, and then restoring it to the complete signature through the recovery function after passing the verification, can determine which signature is wrong. This way it can be determined which node may be the evil node.

The collection node can use the corresponding public key share to verify the signature share in the received Sign-share message. Specifically, the collection node can use the corresponding public key share to calculate the signature share and obtain a hash value, recorded as hash ₁ . It can also perform the same hash calculation on the original message to obtain hash′ ₁ . If hash ₁ and hash′ ₁ are equal, it can be proved that the original message was sent by node 1 and has not been tampered with during the transmission process. In this way, the correctness of the signature share is verified. Similarly, other signature shares can also be verified, which will not be described again.

S330: The collection node broadcasts the full-commit-proof message containing the complete signature to the consensus node.

As mentioned above, after the collection node collects at least the first threshold signature share and recovers the first complete signature σ, it can broadcast the full-commit-proof containing the first complete signature σ to Replicas.

S340: Each consensus node that receives the full-commit-proof message obtains a random number seed based on the complete signature therein.

Random number seed refers to the initial value used to generate pseudo-random numbers in a pseudo-random number generator. For a pseudo-random number generator, starting from the same random number seed, the same random number sequence can be obtained. For a single machine, the random number seed can be determined by the current status of the computer, such as the current time. For distributed systems, the same random number seed must be generated on each node to generate the same random number based on the same random number seed in system contracts/business contracts/blockchain platform functions, etc., and should not Random numbers are generated by any node in a controllable, predictable, and revocable manner. This needs to be determined jointly by the nodes participating in the consensus. Moreover, considering that distributed networks are often asynchronous networks or semi-synchronous networks, from the perspective of immediacy, random numbers need to be generated and used when the transactions in the current block are executed.

After the above steps S310-S330, under normal circumstances each consensus node can obtain the same complete signature. Of course, considering the fault-tolerant nature of the distributed system, there should be at least a quorum of consensus nodes in a blockchain network using the SBFT consensus algorithm, each of which can obtain the same complete signature.

Before generating the random number seed, each consensus node can also use the threshold signature algorithm to generate the total public key corresponding to the private key share to verify the correctness of the complete signature.

The above example in Figure 7 uses SBFT as an example to illustrate the method of generating random number seeds on the chain in the embodiment of this specification. In fact, it can also be applied to variant consensus algorithms of SBFT. SBFT and its variants can be collectively referred to as SBFT-like consensus algorithms. Similarly, the Hotstuff consensus algorithm improved based on PBFT can also be applied to the method of generating random number seeds on the chain in the application embodiment. As mentioned above, the introduction of View-Change in PBFT is to maintain the activity of the distributed system under the assumption of semi-synchronization of the network. Typically, the view switching process of replacing the master node is triggered when the master node fails or does evil. During the view switching process, the state recovery on each node needs to be considered, so that each node in the distributed network can eventually reach the same block state, thus meeting the consistency requirements. As mentioned before, due to the complexity of the many-to-many message interaction model, PBFT is difficult to apply to large-scale networks, that is, it is difficult to expand.

The introduction of HotStuff also solved the scalability problem. It uses technologies such as threshold signatures, linear view changes, and consensus state trees. The core of HotStuff revolves around three rounds of consensus voting. The original paper proposed three forms: simple HotStuff (Basic HotStuff), chained HotStuff (Chained HotStuff), and event-driven HotStuff (Event-Driven HotStuff). Basic HotStuff is the basic process of the latter two consensuses. Among them, the views are continuously switched in a monotonically increasing manner. There is a unique master node in each view that is responsible for proposing, collecting and forwarding messages, and generating QC. The QC is the abbreviation of Quorum Certificate, which means certificate. After the master node receives the voting message (with signature) of at least quorum nodes for a proposal, it uses the threshold signature to synthesize it into a QC. This QC can be understood as the complete signature generated by the threshold signature, indicating that a consensus has been reached on the proposal. The entire process of Basic HotStuff can be shown in Figure 8, including: New-View: Each node sends the previous round of view number, block hash and its own prepareQC to the Leader node through New-View. The New-View message may include the view number v-1 of the previous round and the hash value H (Block-1) of the previous block.

The Leader node (also called the collection node in this manual) calculates the highest QC based on the highest prepareQC in the status tree sent by each node included in the received quorum New-View message. The Leader node broadcasts Prepare messages to other consensus nodes. The Prepare message can include the view number v (correctly it should be the view number of the previous round + 1), and can also include the ordered transaction set packaged by the Leader node.

Prepare voting stage: After each consensus node receives the Prepare message and passes the verification, it sends a Prepare-Vote message for the current proposal to the Leader node. Among them, each consensus node uses its own private key share for signature. Each consensus node sends a Prepare-Vote message to the Leader node. The Prepare-Vote message can include the hash value of the ordered transaction set packaged by the Leader (can be expressed as H (block)), and can also include the consensus node using its own private key share pair including (Prepare-Vote, v, H (block) The first signature share of the content (here set to PartialSig1).

When the Leader master node receives Prepare-Vote messages for the current proposal from at least quorum different consensus nodes, it obtains the first complete signature by aggregating at least quorum PartialSig1, and then broadcasts the Precommit message to each consensus node.

Precommit voting stage: After each other consensus node receives the Precommit message and passes the verification, it sends a Precommit-Vote message to the master node. Similarly, the Precommit-Vote message contains the second signature share (here set to PartialSig2) generated by the consensus node using its own private key.

The Leader node collects at least quorum Precommit-vote messages, obtains the second complete signature by aggregating at least quorum PartialSig2, and then broadcasts it to other consensus nodes through Commit messages. The Commit message sent by the master node is similar to the COMMIT phase in PBFT.

Commit voting stage: After each other consensus node receives the Commit message and passes the verification, it sends a Commit-Vote message to the master node. Similarly, the Commit-Vote message contains the third signature share generated by the consensus node using its own private key (here set to PartialSig3).

When the Leader node collects at least quorum Commit-vote messages, it obtains the third complete signature by aggregating at least quorum PartialSig3, and then broadcasts it to other consensus nodes through Decide messages.

In the above process, during the Precommit voting stage, each consensus node that receives the broadcast message obtains a random number seed based on the complete signature therein. The complete signature can be a complete signature obtained by the Leader node after aggregating at least quorum PartialSig2.

In the above process, similarly, during the Commit voting stage, each consensus node that receives the broadcast message obtains a random number seed based on the complete signature therein. The complete signature can be a complete signature obtained by the Leader node after aggregating at least quorum PartialSig3. Furthermore, each consensus node that receives the broadcast message obtains a random number seed based on the complete signature therein.

The above-mentioned PartialSig2 or PartialSig3 can be a signature share generated by the consensus node using its own private key share to sign the original message containing the unique value of the original transaction list in this consensus based on the threshold signature algorithm.

The unique value of the original transaction list may include: the original transaction list itself or a hash value of the original transaction list.

The original message also includes the random number seed or block hash generated in the previous block.

Wherein, after the collection node collects at least a threshold number of signature shares and before obtaining a complete signature, it further includes: verifying each signature share using the corresponding public key share.

Wherein, after obtaining the complete signature and before obtaining the random number seed, the method further includes: verifying the complete signature using a total public key.

The number of private key shares/public key shares of the threshold signature algorithm is equal to the number of consensus nodes, and the threshold value of the threshold signature algorithm is equal to the quorum of the consensus algorithm used by the blockchain.

Based on the above method, the method may also include: each consensus node puts the obtained random number seed into the block header of the current block generated.

Based on the above method, the method may also include: each consensus node generates random numbers based on the generated random number seeds.

As mentioned before, in voting-based consensus algorithms, there is often a final round of voting, which can be broadcast directly to each other or through gossip protocols, such as commit messages in PBFT, pre-commit messages in Tendermint, and HoneyBadger. Messages used for threshold decryption, etc.

In addition to broadcasting, the messages in the last round of voting can also be collected by a node, aggregated and then broadcast to other nodes, such as the commit message in Hotstuff, and the Sign-share message in SBFT. The solution provided in this manual is applicable to the situation where there is a final round of voting in the consensus algorithm before executing the transaction, so as to reach a consensus on the transaction list to be executed and at the same time reach a consistent random number seed, which meets the requirements of consistency, immediacy, and impossibility. Predictable, uncontrollable and irrevocable.

This specification provides a method for generating random number seeds on the blockchain, including: in the last round of voting before transaction execution, each consensus node uses its own private key share to include the votes in this consensus based on the threshold signature algorithm. Sign the original message with the value, generate a signature share, and send the signature share to at least one collection node;

The collection node passes the collected signature shares of at least a threshold number through the recovery function corresponding to the private key share generated by the threshold signature algorithm to obtain a complete signature; the collection node broadcasts the complete signature to the consensus node; the received Each consensus node of the complete signature obtains a random number seed based on the complete signature.

The voting value includes: the original transaction list itself or the hash value of the original transaction list.

Wherein, the original message also includes a block number and/or a timestamp.

A method of generating a block header, based on the above method, also includes: each consensus node puts the obtained random number seed into the block header of the current block generated.

A method of generating random numbers on the blockchain, based on any of the above methods, also includes: each consensus node generates random numbers based on the generated random number seeds.

According to the characteristics of the threshold signature algorithm, through the above scheme, the signatures recovered by all nodes must be consistent, and the signature is uncontrollable and unpredictable, and it must be jointly signed by nodes that reach the threshold to be successfully recovered, so it is consistent with the randomness on the chain. number requirements.

Embodiments of this specification also provide a method for generating random number seeds on the blockchain, which is applied to a system including several consensus nodes and collection nodes, including: in the last round of voting before transaction execution, each consensus node generates a random number seed based on a threshold. Signature algorithm uses its own private key share to sign the original message containing the voting value in this consensus, generates a signature share, and sends the signature share to at least one collection node; the collection node will collect at least a threshold number The signature share is passed through the recovery function corresponding to the private key share generated by the threshold signature algorithm to obtain a complete signature; the collection node broadcasts the complete signature to the consensus node; each consensus node that receives the complete signature is based on the The complete signature gets the random number seed.

In the 1990s, improvements in a technology could be clearly distinguished as hardware improvements (for example, improvements in circuit structures such as diodes, transistors, switches, etc.) or software improvements (improvements in method processes). However, with the development of technology, many improvements in today's method processes can be regarded as direct improvements in hardware circuit structures. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that an improvement of a method flow cannot be implemented using hardware entity modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic functions are determined by the user programming the device. Designers can program themselves to "integrate" a digital system on a PLD, instead of asking chip manufacturers to design and produce dedicated integrated circuit chips. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented using "logic compiler" software, which is similar to the software compiler used in program development and writing, and before compilation The original code must also be written in a specific programming language, which is called Hardware Description Language (HDL), and HDL is not just one kind, but there are many, such as ABEL (Advanced Boolean Expression Language) , AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., are currently the most commonly used The two are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also know that by simply logically programming the method flow using the above-mentioned hardware description languages and programming it into the integrated circuit, the hardware circuit that implements the logical method flow can be easily obtained.

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 (eg, software or firmware) executable by the (micro)processor. , logic gates, switches, Application Specific Integrated Circuit (ASIC), programmable logic controllers and embedded microcontrollers. Examples of controllers include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, For Microchip PIC18F26K20 and Silicone Labs C8051F320, the memory controller can also be implemented as part of the memory's control logic. Those skilled in the art also know that in addition to implementing the controller in the form of pure computer-readable program code, the controller can be completely programmed with logic gates, switches, application-specific integrated circuits, programmable logic controllers and embedded logic by logically programming the method steps. Microcontroller, etc. to achieve the same function. Therefore, this controller can be considered as a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the means for implementing various functions can be considered as structures within hardware components as well as software modules implementing the methods.

The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, this description does not rule out that with the development of computer technology in the future, the computer that implements the functions of the above embodiments may be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular phone, a camera phone, a smart phone, or a personal digital assistant. , media player, navigation device, email device, game console, tablet, wearable device, or a combination of any of these devices.

Although one or more embodiments of this specification provide method operation steps as described in the embodiments or flow charts, more or fewer operation steps may be included based on conventional or non-inventive means. The sequence of steps listed in the embodiment is only one way of executing the sequence of many steps, and does not represent the only execution sequence. When the actual device or terminal product is executed, it may be executed sequentially or in parallel according to the methods shown in the embodiments or figures (for example, a parallel processor or a multi-thread processing environment, or even a distributed data processing environment). The terms "comprises," "comprises" or any other variation thereof are intended to cover a non-exclusive inclusion such that a process, method, product or apparatus including a list of elements includes not only those elements but also others not expressly listed elements, or also elements inherent to the process, method, product or equipment. Without further limitation, it does not exclude the presence of additional identical or equivalent elements in a process, method, product or apparatus including the stated elements. For example, if the words "first" and "second" are used to express names, they do not indicate any specific order.

For the convenience of description, when describing the above device, the functions are divided into various modules and described separately. Of course, when implementing one or more of this specification, the functions of each module can be implemented in the same or multiple software and/or hardware, or the modules that implement the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. . The device embodiments described above are only illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated. to another system, or some features can be ignored, or not implemented. On the other hand, the coupling or direct coupling or communication connection between each other shown or discussed may be through some interfaces, and the indirect coupling or communication connection of the devices or units may be in electrical, mechanical or other forms.

The specification is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the specification. It will be understood that each process and/or block in the flowchart illustrations and/or block diagrams, and combinations of processes 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 device to produce a machine, such that the instructions executed by the processor of the computer or other programmable data processing device produce a use A device for realizing the functions specified in one process or multiple processes of the flowchart and/or one block or multiple blocks of the block diagram.

These computer program instructions may also be stored in a computer-readable memory that causes a computer or other programmable data processing apparatus to operate in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including the instruction means, the instructions The device implements the functions specified in a process or processes of the flowchart and/or a block or blocks of the block diagram.

These computer program instructions may also be loaded onto a computer or other programmable data processing device, causing a series of operating steps to be performed on the computer or other programmable device to produce computer-implemented processing, thereby executing on the computer or other programmable device. Instructions provide steps for implementing the functions specified in a process or processes of a flowchart diagram and/or a block or blocks of a block diagram.

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

Memory may include non-permanent storage in computer-readable media, random access memory (RAM) and/or non-volatile memory in the form of read-only memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

Computer-readable media includes both persistent and non-volatile, removable and non-removable media that can be implemented by any method or technology for storage of information. Information may be computer-readable instructions, data structures, modules of programs, 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), and 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 disc (DVD) or other optical storage, Magnetic tape, magnetic tape storage, graphene storage or other magnetic storage devices or any other non-transmission medium can be used to store information that can be accessed by a computing device. As defined in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.

It should be understood by those skilled in the art that one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment that combines software and hardware aspects. Furthermore, one or more embodiments of the present description may employ a computer program implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein. Product form.

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

Each embodiment in this specification is described in a progressive manner. The same and similar parts between the various embodiments can be referred to each other. Each embodiment focuses on its differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple. For relevant details, please refer to the partial description of the method embodiment. In the description of this specification, reference to the terms "one embodiment," "some embodiments," "an example," "specific examples," or "some examples" or the like means that specific features are described in connection with the embodiment or example. , structures, materials or features are included in at least one embodiment or example of this specification. In this specification, the schematic expressions of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the specific features, structures, materials or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, those skilled in the art may combine and combine different embodiments or examples and features of different embodiments or examples described in this specification unless they are inconsistent with each other.

The above descriptions are only examples of one or more embodiments of this specification, and are not intended to limit one or more embodiments of this specification. To those skilled in the art, various modifications and changes may be made to one or more embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of this specification shall be included in the scope of the claims.

Claims

A method of generating random number seeds on the blockchain, including:

In the Sign-share phase of the SBFT-like consensus, each consensus node uses its own private key share to sign the original message containing the unique value of the original transaction list in this consensus based on the threshold signature algorithm, generates a signature share, and sends the signature The share is added to the Sign-share message and sent to at least one collection node;

After the collection node collects at least a threshold number of Sign-share messages, at least a threshold number of signature shares among them are passed through the recovery function corresponding to the private key share generated by the threshold signature algorithm to obtain a complete signature;

The collection node broadcasts the full-commit-proof message containing the complete signature to the consensus node;

Each consensus node that receives the full-commit-proof message obtains a random number seed based on the complete signature in it.
The method according to claim 1, the unique values of the original transaction list include:

The original transaction list itself or the hash value of the original transaction list.
The method of claim 1, wherein the original message further includes a block number and/or a timestamp.
The method of claim 1, wherein the original message further includes a random number seed or block hash generated in the previous block.
The method according to claim 1, after the collection node collects at least a threshold number of Sign-share messages and before obtaining a complete signature, it also includes:

The signature share in each Sign-share message is verified using the corresponding public key share.
The method according to claim 1, after obtaining the complete signature and before obtaining the random number seed, further comprising:

The complete signature is verified using the total public key.
The method according to any one of claims 1 to 6, the number of private key shares/public key shares of the threshold signature algorithm is equal to the number of consensus nodes, and the threshold value of the threshold signature algorithm is equal to the number of consensus nodes. The quorum of the consensus algorithm used by the blockchain is equal.
A method of generating block headers, based on any of the above methods 1-7, also includes:

Each consensus node puts the obtained random number seed into the block header of the current block generated.
A method of generating random numbers on the blockchain, based on any of the above methods 1-7, also includes:

Each consensus node generates random numbers based on the generated random number seeds.
A method of generating random number seeds on the blockchain, including:

In the Pre-Commit/Commit voting stage of the Hotstuff-like consensus, each consensus node uses its own private key share to sign the original message containing the unique value of the original transaction list in this consensus based on the threshold signature algorithm, and generates a signature share. And add the signature share to the broadcast message and send it to the collection node;

After collecting at least a threshold number of broadcast messages, the collection node passes at least a threshold number of signature shares among them through the recovery function corresponding to the private key share generated by the threshold signature algorithm to obtain a complete signature, and broadcasts the message containing the complete signature to Consensus node;

Each consensus node that receives the broadcast message obtains a random number seed based on the complete signature therein.
The method of claim 10, wherein the unique values of the original transaction list include:

The original transaction list itself or the hash value of the original transaction list.
The method of claim 10, wherein the original message further includes a random number seed or block hash generated in the previous block.
The method according to claim 10, after the collection node collects at least a threshold number of Sign-share messages and before obtaining a complete signature, it further includes:

The signature share in each Sign-share message is verified using the corresponding public key share.
The method according to claim 10, after obtaining the complete signature and before obtaining the random number seed, it further includes:

The complete signature is verified using the total public key.
The method according to any one of claims 10 to 14, the number of private key shares/public key shares of the threshold signature algorithm is equal to the number of consensus nodes, and the threshold value of the threshold signature algorithm is equal to the number of consensus nodes. The quorum of the consensus algorithm used by the blockchain is equal.
A method of generating block headers, based on any of the methods 10-15 above, also includes:

Each consensus node puts the obtained random number seed into the block header of the current block generated.
A method of generating random numbers on the blockchain, based on any of the methods 10-15 above, also includes:

Each consensus node generates random numbers based on the generated random number seeds.
A method of generating random number seeds on the blockchain, applied to systems including several consensus nodes and collection nodes, including:

In the last round of voting before transaction execution, each consensus node uses its own private key share to sign the original message containing the voting value in this consensus based on the threshold signature algorithm, generates a signature share, and sends the signature share to at least one collection node;

The collection node will collect at least a threshold number of signature shares through the recovery function corresponding to the private key share generated by the threshold signature algorithm to obtain a complete signature;

The collection node broadcasts the complete signature to the consensus node;

Each consensus node that receives the complete signature obtains a random number seed based on the complete signature.
The method of claim 18, the voting value includes:

The original transaction list itself or the hash value of the original transaction list.
The method of claim 18, the original message further includes a block number and/or a timestamp.
The method of claim 18, wherein the original message further includes a random number seed or block hash generated in the previous block.
The method of claim 18, after the collection node collects at least a threshold number of signature shares and before obtaining a complete signature, it further includes:

Each signature share is verified using the corresponding public key share.
The method according to claim 18, after obtaining the complete signature and before obtaining the random number seed, further comprising:

The complete signature is verified using the total public key.
The method according to any one of claims 18-23, the number of private key shares/public key shares of the threshold signature algorithm is equal to the number of consensus nodes, and the threshold value of the threshold signature algorithm is equal to the number of consensus nodes. The quorum of the consensus algorithm used by the blockchain is equal.
A method of generating block headers, based on any of the methods 18-24 above, also includes:

Each consensus node puts the obtained random number seed into the block header of the current block generated.
A method of generating random numbers on the blockchain, based on any of the above methods 18-24, also includes:

Each consensus node generates random numbers based on the generated random number seeds.
A method of generating random number seeds on the blockchain, applied to systems including several consensus nodes and collection nodes, including:

In the last round of voting before transaction execution, each consensus node uses its own private key share to sign the original message containing the voting value in this consensus based on the threshold signature algorithm, generates a signature share, and sends the signature share to at least one collection node;

The collection node will collect at least a threshold number of signature shares through the recovery function corresponding to the private key share generated by the threshold signature algorithm to obtain a complete signature;

The collection node broadcasts the complete signature to the consensus node;

Each consensus node that receives the complete signature obtains a random number seed based on the complete signature.