WO2023185051A1 - 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 - Google Patents

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 Download PDF

Info

Publication number
WO2023185051A1
WO2023185051A1 PCT/CN2022/135437 CN2022135437W WO2023185051A1 WO 2023185051 A1 WO2023185051 A1 WO 2023185051A1 CN 2022135437 W CN2022135437 W CN 2022135437W WO 2023185051 A1 WO2023185051 A1 WO 2023185051A1
Authority
WO
WIPO (PCT)
Prior art keywords
signature
consensus
threshold
share
random number
Prior art date
Application number
PCT/CN2022/135437
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 WO2023185051A1 publication Critical patent/WO2023185051A1/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, including:
  • a method of generating random number seeds on the blockchain including:
  • each consensus node uses its own private key share to sign the original message containing the unique value of the original transaction list in this consensus based on the threshold signature algorithm, generates a signature share, and adds the signature share to the broadcast In the commit message;
  • Each consensus node obtains a random number seed based on the complete signature.
  • the method includes:
  • the consensus node uses its own private key share to sign the original message, generates a signature share, and adds the signature share to the broadcast message;
  • the consensus node After the consensus node collects at least a threshold number of the messages, it passes at least a quorum number of signature shares through the recovery function corresponding to the private key share generated by the threshold signature algorithm to obtain a complete signature;
  • the consensus node obtains a random number seed based on the complete signature.
  • a blockchain system including several consensus nodes, including:
  • each consensus node uses its own private key share to sign the original message containing the unique value of the original transaction list in this consensus based on the threshold signature algorithm, generates a signature share, and adds the signature share to the broadcast In the commit message;
  • each consensus node After each consensus node collects at least a threshold number of commit messages, it passes at least a threshold number of signature shares through the recovery function corresponding to the private key share/public key generated by the threshold signature algorithm to obtain a complete signature;
  • Each consensus node obtains a random number seed based on the complete signature.
  • a consensus node in a blockchain system The consensus algorithm adopted by the blockchain system outputs consensus results by broadcasting messages to each other in the final stage, wherein:
  • the consensus node uses its own private key share to sign the original message, generates a signature share, and adds the signature share to the broadcast message;
  • the consensus node After the consensus node collects at least a threshold number of the messages, it passes at least the threshold number of signature shares through the recovery function corresponding to the private key share/public key generated by the threshold signature algorithm to obtain a complete signature;
  • the consensus node obtains a random number seed based on the complete signature.
  • 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.
  • 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.
  • 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 NormalCase 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.
  • a consensus process that is, a three-stage process of PBFT, it can include:
  • the pre-prepare request includes message m;
  • nodes 1, 2, and 3 After nodes 1, 2, and 3 receive the pre-prepare request, if they check that the message m is legal, they will broadcast the hash value of the message m they received through the prepare message (the broadcast content generally does not include the message m itself, because the message m includes several original transaction requests, the volume is generally relatively large). Specifically, node 1 diffuses the prepare message to nodes 0, 2, and 3, node 2 diffuses the prepare message to nodes 0, 1, and 3, and node 3 diffuses the prepare message to nodes 0, 1, and 2. Correspondingly, each node also receives prepare messages broadcast by other nodes.
  • Each node adds the prepare message it sends (which contains the hash value of message m, representing its own approval) and the prepared message it receives (which contains the hash value of message m, which represents the approval of other nodes) to the local log ( Log). If a node collects at least Quorum number of legal pp messages/p messages from different nodes (including pre-prepare, prepare messages sent by itself, and prepare messages received), it changes to the prepared state.
  • 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:
  • each consensus node uses its own private key share to sign the original message containing the unique value of the original transaction list in this consensus based on the threshold signature algorithm, generates a signature share, and adds the signature share into 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:
  • 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 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 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 signature shares ⁇ 3,0 , ⁇ 3,1 , ⁇ 3,2 and ⁇ 3,3 , which will certainly satisfy 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 .
  • 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.
  • 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 execution of the transactions contained in this block are 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 following describes a method of generating random number seeds on the blockchain from the perspective of a consensus node in the blockchain network in a blockchain network that first agrees on the transaction list and then executes the transactions in the consensus transaction list, and In the adopted consensus algorithm, the consensus results are output by broadcasting messages to each other in the last stage.
  • the consensus node execution is as shown in Figure 6:
  • the consensus node Based on the threshold signature algorithm, the consensus node uses its own private key share to sign the original message, generates a signature share, and adds 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 signature shares ⁇ 3,0 , ⁇ 3,1 , ⁇ 3,2 and ⁇ 3,3 , which will certainly satisfy 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 .
  • 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.
  • each consensus node uses its own private key share to sign the original message containing the unique value of the original transaction list in this consensus based on the threshold signature algorithm, generates a signature share, and adds the signature share to the broadcast In the commit message;
  • the at least quorum number of signature shares are passed through the recovery function corresponding to the private key share generated by the threshold signature algorithm to obtain a complete signature;
  • Each consensus node obtains a random number seed based on the complete signature.
  • 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 may also include a block number and/or a timestamp.
  • the original message may also include a random number seed or block hash generated in the previous block.
  • each consensus node collects at least a threshold number of commit messages and before obtaining a complete signature, it also includes:
  • Each consensus node uses the public key share corresponding to its own private key share to verify the signature share in each commit message.
  • the complete signature is verified using the 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.
  • Each consensus node puts the obtained random number seed into the block header of the current block generated.
  • the following introduces a method of generating random numbers on the blockchain provided in this manual. On the basis of the above, it can also include:
  • Each node generates random numbers based on the generated random number seed.
  • the consensus algorithm adopted by the blockchain system outputs consensus results by broadcasting messages to each other in the final stage, where:
  • the consensus node uses its own private key share to sign the original message, generates a signature share, and adds the signature share to the broadcast message;
  • the consensus node collects at least a threshold number of the messages
  • the at least threshold number of signature shares are passed through a recovery function corresponding to the private key share generated by the threshold signature algorithm to obtain a complete signature
  • the consensus node obtains a random number seed based on the complete signature.
  • the unique value of the original transaction list may include: the original transaction list itself or the hash value of the original transaction list.
  • the original message may also include a block number and/or a timestamp.
  • the original message may also include the random number seed generated in the previous block.
  • the consensus node collects at least a threshold number of commit messages and before obtaining a complete signature, it also includes:
  • the consensus node uses the public key share corresponding to its own private key share to verify the signature share in each commit message.
  • the consensus node After the consensus node obtains the complete signature and before obtaining the random number seed, it also includes:
  • the complete signature is verified using the 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 in the blockchain system, and the threshold value of the threshold signature algorithm is equal to the quorum.
  • the consensus node puts the obtained random number seed into the block header of the generated current block.
  • the following introduces the consensus nodes in a blockchain system provided by this manual. On the basis of the above, it can also include:
  • the consensus node generates random numbers based on the generated random number seeds.
  • PLD Programmable Logic Device
  • FPGA Field Programmable Gate Array
  • HDL Hardware Description Language
  • ABEL Advanced Boolean Expression Language
  • AHDL Altera Hardware Description Language
  • Confluence a specific programming language
  • CUPL Cornell University Programming Language
  • HDCal a Hardware Description Language
  • JHDL Java Hardware Description Language
  • Lava Lava
  • Lola MyHDL
  • PALASM RHDL
  • VHDL Very-High-Speed Integrated Circuit 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, AtmelAT91SAM, Microchip For the 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é de génération de valeurs de départ de nombre aléatoire sur une chaîne de blocs, et un système et un nœud de consensus. Le procédé comprend les étapes suivantes : dans une étape de validation de PBFT, sur la base d'un algorithme de signature seuil, chaque nœud de consensus signe, à l'aide de son propre partage de clé privée, un message d'origine, qui comprend une valeur spécifique d'une liste de transactions d'origine dans le consensus actuel, de façon à générer un partage de signature, et ajoute le partage de signature à un message de validation de diffusion ; après avoir collecté au moins un nombre seuil de messages de validation, chaque nœud de consensus obtient une signature complète en soumettant au moins un nombre seuil de partages de signature à une fonction de récupération correspondant au partage de clé privée, qui est générée à l'aide de l'algorithme de signature seuil ; et chaque nœud de consensus obtient des valeurs de départ de nombre aléatoire sur la base de la signature complète.
PCT/CN2022/135437 2022-03-29 2022-11-30 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 WO2023185051A1 (fr)

Applications Claiming Priority (2)

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

Publications (1)

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

Family

ID=82670039

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/135437 WO2023185051A1 (fr) 2022-03-29 2022-11-30 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

Country Status (2)

Country Link
CN (1) CN114884652A (fr)
WO (1) WO2023185051A1 (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 (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114884652A (zh) * 2022-03-29 2022-08-09 蚂蚁区块链科技(上海)有限公司 一种区块链上产生随机数种子的方法、系统和共识节点

Citations (3)

* 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
CN113642019A (zh) * 2021-08-16 2021-11-12 中国人民解放军国防科技大学 一种双层分组拜占庭容错共识方法及系统
CN114884652A (zh) * 2022-03-29 2022-08-09 蚂蚁区块链科技(上海)有限公司 一种区块链上产生随机数种子的方法、系统和共识节点

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 (3)

* 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
CN113642019A (zh) * 2021-08-16 2021-11-12 中国人民解放军国防科技大学 一种双层分组拜占庭容错共识方法及系统
CN114884652A (zh) * 2022-03-29 2022-08-09 蚂蚁区块链科技(上海)有限公司 一种区块链上产生随机数种子的方法、系统和共识节点

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
CN114884652A (zh) 2022-08-09

Similar Documents

Publication Publication Date Title
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
EP3566397B1 (fr) Réalisation d'un changement d'un noeud primaire dans un système distribué
EP3566392B1 (fr) Réalisation d'un consensus entre des noeuds de réseau dans un système distribué
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
EP3560142B1 (fr) Exécution d'un processus de reprise pour un noeud de réseau dans un système distribué
CN110689349B (zh) 一种区块链中的交易哈希值存储和搜索方法及装置
WO2020258912A1 (fr) Procédé de consensus de chaîne de blocs, dispositif et système
JP7328237B2 (ja) コンピュータにより実施される投票処理およびシステム
WO2023056974A1 (fr) Procédé consensus, système de chaîne de blocs et noeuds de consensus
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
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
CN114640451A (zh) 区块链上实现分布式密钥生成的方法、系统和共识节点
CN113761071B (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
WO2023016426A1 (fr) Procédé et appareil d'accord binaire asynchrone, dispositif électronique et support de stockage
WO2023056966A1 (fr) Procédé de consensus, système de chaîne de blocs et nœud de consensus
WO2023207080A1 (fr) Procédé de traitement de données dans une chaîne de blocs, et nœud de chaîne de blocs
CN118473658A (zh) 区块链上实现分布式密钥生成的方法、系统和共识节点
CN115174048A (zh) 一种共识方法、系统和共识节点
WO2024207765A1 (fr) Procédé de proposition de transaction et nœud de consensus dans un système de chaîne de blocs, et système de chaîne de blocs
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
CN114640452B (zh) 启动区块链上分布式密钥生成过程的方法和系统
CN116032461A (zh) 一种区块链上实现分布式密钥生成的方法和节点
CN114640450B (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: 22934869

Country of ref document: EP

Kind code of ref document: A1