WO2023185045A1 - Procédé et système de génération de valeurs de départ de nombre aléatoire sur une chaîne de blocs, et noeud de consensus - Google Patents

Procédé et système de génération de valeurs de départ de nombre aléatoire sur une chaîne de blocs, et noeud de consensus Download PDF

Info

Publication number
WO2023185045A1
WO2023185045A1 PCT/CN2022/135233 CN2022135233W WO2023185045A1 WO 2023185045 A1 WO2023185045 A1 WO 2023185045A1 CN 2022135233 W CN2022135233 W CN 2022135233W WO 2023185045 A1 WO2023185045 A1 WO 2023185045A1
Authority
WO
WIPO (PCT)
Prior art keywords
signature
consensus
node
share
threshold
Prior art date
Application number
PCT/CN2022/135233
Other languages
English (en)
Chinese (zh)
Inventor
徐文博
Original Assignee
蚂蚁区块链科技(上海)有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 蚂蚁区块链科技(上海)有限公司 filed Critical 蚂蚁区块链科技(上海)有限公司
Publication of WO2023185045A1 publication Critical patent/WO2023185045A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

Definitions

  • 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.
  • Blockchain is a new application model of computer technology such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm.
  • 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.
  • 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.
  • 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 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • each node (or multiple nodes) runs a blockchain program.
  • 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.
  • 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).
  • 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).
  • 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.
  • 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.
  • the View Change protocol phase may also be initiated to replace the master node.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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. ).
  • node 1 diffuses the prepare message to nodes 0, 2, and 3
  • node 2 diffuses the prepare message to nodes 0, 1, and 3
  • node 3 diffuses the prepare message to nodes 0, 1, and 2.
  • 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.
  • each node participating in the consensus 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.
  • 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.
  • 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.
  • sha384 is 384bits
  • 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.
  • B After receiving the message, B uses A’s public key to verify the signature.
  • 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.
  • 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.
  • threshold signature mechanism based on RSA
  • ECDSA Elliptic Curve Digital Signature Algorithm, Elliptic Curve Digital Signature Algorithm
  • Schnorr a knowledge proof mechanism based on discrete logarithm problems
  • Threshold signature mechanism threshold signature mechanism based on BLS (Boneh-Lynn-Shacham Signature), etc.
  • 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.
  • 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.
  • n private key shares can be held by each blockchain consensus node.
  • each blockchain consensus node can hold the same 1 total public key.
  • 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.
  • 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.
  • 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 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.
  • the block number (that is, the number) can also be as the content in the original message.
  • 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.
  • 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.
  • 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.
  • 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.
  • the unique value of the original transaction list that can be included in this original message can be the original transaction list.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • any node or other device holding the total public key can use the total public key to verify the correctness of the complete signature.
  • the total public key can be used to verify the integrity of the complete signature.
  • 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.
  • node 1 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. .
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 .
  • 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.
  • 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 ).
  • 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.
  • 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 ).
  • 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 ).
  • 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 ).
  • 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.
  • a pseudo-random number generator starting from the same random number seed, the same random number sequence can be obtained.
  • the random number seed can be determined by the current status of the computer, such as the current time.
  • 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.
  • 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.
  • each consensus node can obtain the same complete signature.
  • PBFT consensus algorithm 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.
  • 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.
  • a random number seed can be generated on the blockchain.
  • the chain platform code can be executed based on the random number seed of S130.
  • 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.
  • the random library in python and the random library in java also provide similar random number generation methods.
  • the same random number can be generated under the same random number generation algorithm.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • state root is the hash value of the root of the MPT tree composed of the status of all accounts in the current block
  • 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.
  • this instruction can add a field in the block header - "random number seed", which is the random number seed in S130.
  • random number seed generated in this block can be recorded on the blockchain ledger.
  • 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.
  • 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
  • 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.
  • the threshold quorum
  • the complete signatures are the same, and the random number seeds generated by this quorum number of nodes must also be the same.
  • 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.
  • 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 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • any node or other device holding the total public key can use the total public key to verify the correctness of the complete signature.
  • the total public key can be used to verify the integrity of the complete signature.
  • 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.
  • node 1 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. .
  • 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.
  • 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.
  • 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.
  • 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 1 and 2 respectively.
  • 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 .
  • 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.
  • 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 ).
  • 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.
  • 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 ).
  • 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 ).
  • 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 ).
  • the consensus node obtains a random number seed based on the complete signature.
  • 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.
  • 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.
  • 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.
  • 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).
  • the SBFT process is as follows:
  • the client (c in the figure) initiates a transaction request to the primary node (Primary).
  • Primary the process of a client initiating a transaction request.
  • Each transaction request can be sent directly to the Primary or forwarded to the Primary through other nodes.
  • Pre-prepare phase 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 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).
  • 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 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.
  • 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
  • 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.
  • 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.
  • the request can be resent to all Replicas.
  • SBFT Compared with PBFT, SBFT only needs to send 1/3 of its number of messages and reaches consensus faster.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • the block number (that is, the number) can also be as the content in the original message.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the unique value of the original transaction list that can be included in this original message can be the original transaction list.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • any node or other device holding the total public key can use the total public key to verify the correctness of the complete signature.
  • the total public key can be used to verify the integrity of the complete signature.
  • 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.
  • node 1 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. .
  • 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.
  • 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.
  • 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 1 . It can also perform the same hash calculation on the original message to obtain hash′ 1 . If hash 1 and hash′ 1 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.
  • 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.
  • 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.
  • a pseudo-random number generator starting from the same random number seed, the same random number sequence can be obtained.
  • the random number seed can be determined by the current status of the computer, such as the current time.
  • 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.
  • 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.
  • each consensus node can obtain the same complete signature.
  • SBFT consensus algorithm 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.
  • 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.
  • each consensus node 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.
  • a random number seed can be generated on the blockchain.
  • PBFT is difficult to apply to large-scale networks, that is, it is difficult to expand.
  • 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.
  • the master node 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.
  • each consensus node 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).
  • the Leader master node 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 second signature share here set to PartialSig2
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the method may also include: each consensus node puts the obtained random number seed into the block header of the current block generated.
  • the method may also include: each consensus node generates random numbers based on the generated random number seeds.
  • 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.
  • 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.
  • the original message also includes a block number and/or a timestamp.
  • the original message also includes the random number seed or block hash generated in the previous block.
  • 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.
  • 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.
  • a method of generating a block header 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 also includes: each consensus node generates random numbers based on the generated random number seeds.
  • 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.
  • PLD Programmable Logic Device
  • FPGA Field Programmable Gate Array
  • HDL Hardware Description Language
  • 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.
  • 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.
  • the controller 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.
  • 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.
  • the functions are divided into various modules and described separately.
  • 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.
  • the division of the units is only a logical function division. In actual implementation, there may be other division methods.
  • multiple units or components may be combined or integrated. to another system, or some features can be ignored, or not implemented.
  • 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.
  • 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.
  • a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
  • processors CPUs
  • input/output interfaces network interfaces
  • memory volatile and non-volatile 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.
  • RAM random access memory
  • ROM read-only memory
  • flash RAM flash random access memory
  • 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.
  • PRAM phase change memory
  • SRAM static random access memory
  • DRAM dynamic random access memory
  • RAM random access memory
  • read-only memory read-only memory
  • ROM read-only memory
  • EEPROM electrically erasable programmable read-only memory
  • flash memory or other memory technology
  • compact disc read-only memory CD-ROM
  • DVD digital versatile disc
  • 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.
  • computer-readable media does not include transitory media, such as modulated data signals and carrier waves.
  • 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.
  • computer-usable storage media including, but not limited to, disk storage, CD-ROM, optical storage, etc.
  • program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types.
  • program modules may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communications network.
  • program modules may be located in both local and remote computer storage media including storage devices.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention concerne un procédé et un système de génération d'une valeur de départ de nombre aléatoire sur une chaîne de blocs, et un nœud de consensus. Le procédé comprend les étapes suivantes : dans une phase de partage de signe d'un consensus de type SBFT, chaque nœud de consensus signe, à l'aide d'un partage de clé privée du nœud de consensus, sur la base d'un algorithme de signature seuil, un paquet d'origine contenant une valeur spécifique de liste de transactions d'origine dans le consensus, afin de générer un partage de signature, et ajoute le partage de signature dans un message de partage de signe et envoie le message à au moins un nœud de collecte ; après la collecte d'au moins un nombre seuil de messages de partage de signe, le nœud de collecte applique une fonction de récupération correspondant au partage de clé privée générée par l'algorithme de signature seuil à au moins le nombre seuil des partages de signature afin d'obtenir une signature complète ; le nœud de collecte diffuse un message de preuve de validation complète contenant la signature complète au nœud de consensus ; et chaque nœud de consensus recevant le message de preuve de validation complète obtient une valeur de départ aléatoire sur la base de la signature complète dans le message de preuve de validation complète.
PCT/CN2022/135233 2022-03-29 2022-11-30 Procédé et système de génération de valeurs de départ de nombre aléatoire sur une chaîne de blocs, et noeud de consensus WO2023185045A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210325831.0 2022-03-29
CN202210325831.0A CN114726517A (zh) 2022-03-29 2022-03-29 一种区块链上产生随机数种子的方法、系统和共识节点

Publications (1)

Publication Number Publication Date
WO2023185045A1 true WO2023185045A1 (fr) 2023-10-05

Family

ID=82239300

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/135233 WO2023185045A1 (fr) 2022-03-29 2022-11-30 Procédé et système de génération de valeurs de départ de nombre aléatoire sur une chaîne de blocs, et noeud de consensus

Country Status (2)

Country Link
CN (1) CN114726517A (fr)
WO (1) WO2023185045A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117408718A (zh) * 2023-12-14 2024-01-16 南京邮电大学 一种面向大规模医药溯源的pbft优化方法
CN117978547A (zh) * 2024-03-29 2024-05-03 华东交通大学 Trp-pbft共识方法、系统、存储介质及设备

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114726517A (zh) * 2022-03-29 2022-07-08 蚂蚁区块链科技(上海)有限公司 一种区块链上产生随机数种子的方法、系统和共识节点
CN115392912B (zh) * 2022-10-26 2023-03-14 南方科技大学 随机数生成方法、系统、设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111756823A (zh) * 2020-06-12 2020-10-09 山西警察学院 基于简化拜占庭容错算法的应用于公安系统的开放许可链
CN112636905A (zh) * 2020-12-11 2021-04-09 北京航空航天大学 基于多角色的可扩展共识机制的系统及方法
US20210256011A1 (en) * 2020-02-14 2021-08-19 Vmware, Inc. Linear byzantine agreement
CN114726517A (zh) * 2022-03-29 2022-07-08 蚂蚁区块链科技(上海)有限公司 一种区块链上产生随机数种子的方法、系统和共识节点

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110825349B (zh) * 2019-11-14 2023-03-28 深圳市迅雷网络技术有限公司 随机数生成方法、区块链节点、系统及介质
CN113612604B (zh) * 2021-07-30 2022-05-17 北京航空航天大学 面向异步网络的安全分布式随机数生成方法及装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210256011A1 (en) * 2020-02-14 2021-08-19 Vmware, Inc. Linear byzantine agreement
CN111756823A (zh) * 2020-06-12 2020-10-09 山西警察学院 基于简化拜占庭容错算法的应用于公安系统的开放许可链
CN112636905A (zh) * 2020-12-11 2021-04-09 北京航空航天大学 基于多角色的可扩展共识机制的系统及方法
CN114726517A (zh) * 2022-03-29 2022-07-08 蚂蚁区块链科技(上海)有限公司 一种区块链上产生随机数种子的方法、系统和共识节点

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117408718A (zh) * 2023-12-14 2024-01-16 南京邮电大学 一种面向大规模医药溯源的pbft优化方法
CN117408718B (zh) * 2023-12-14 2024-03-08 南京邮电大学 一种面向大规模医药溯源的pbft优化方法
CN117978547A (zh) * 2024-03-29 2024-05-03 华东交通大学 Trp-pbft共识方法、系统、存储介质及设备
CN117978547B (zh) * 2024-03-29 2024-06-07 华东交通大学 Trp-pbft共识方法、系统、存储介质及设备

Also Published As

Publication number Publication date
CN114726517A (zh) 2022-07-08

Similar Documents

Publication Publication Date Title
WO2023185045A1 (fr) Procédé et système de génération de valeurs de départ de nombre aléatoire sur une chaîne de blocs, et noeud de consensus
US10791107B2 (en) Performing a change of primary node in a distributed system
EP3566392B1 (fr) Réalisation d'un consensus entre des noeuds de réseau dans un système distribué
US10649859B2 (en) Performing a recovery process for a network node in a distributed system
WO2023185051A1 (fr) Procédé de génération de valeurs de départ de nombre aléatoire sur une chaîne de blocs, et système et noeud de consensus
US11895248B2 (en) Method and apparatus for generating blockchain transaction
WO2020258912A1 (fr) Procédé de consensus de chaîne de blocs, dispositif et système
CN110689349B (zh) 一种区块链中的交易哈希值存储和搜索方法及装置
WO2023056974A1 (fr) Procédé consensus, système de chaîne de blocs et noeuds de consensus
WO2023056964A1 (fr) Procédé de consensus, système de chaîne de blocs et nœud de consensus
WO2023056958A1 (fr) Procédé de consensus, système de chaîne de blocs et nœud de consensus
WO2023056967A1 (fr) Procédé de consensus, système de chaîne de blocs et nœuds de consensus
CN114640451A (zh) 区块链上实现分布式密钥生成的方法、系统和共识节点
WO2023185046A1 (fr) Procédé de rotation de nœuds de consensus dans un système de chaîne de blocs, et nœuds et système de chaîne de blocs
WO2023056976A1 (fr) Procédé de consensus, système à chaîne de blocs et nœud de consensus
WO2023056966A1 (fr) Procédé de consensus, système de chaîne de blocs et nœud de consensus
US20220019490A1 (en) Blockchain event processing method and apparatus
CN115174048A (zh) 一种共识方法、系统和共识节点
WO2024092936A1 (fr) Procédé de réalisation d'une génération de clés distribuées sur une chaîne de blocs, système et nœud
WO2024092935A1 (fr) Procédé de réalisation d'une génération de clé distribuée sur une chaîne de blocs, système et nœud
CN114640452B (zh) 启动区块链上分布式密钥生成过程的方法和系统
CN115865341A (zh) 一种区块链上实现分布式密钥生成的方法、系统和节点
CN114640450B (zh) 区块链上实现重传秘密份额与确定失败节点的方法、系统
CN116015621A (zh) 一种区块链上实现分布式密钥生成的方法、系统和节点
CN116032461A (zh) 一种区块链上实现分布式密钥生成的方法和节点

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22934863

Country of ref document: EP

Kind code of ref document: A1