CN115189871A - Byzantine fault-tolerant consensus algorithm based on verifiable random function and threshold signature - Google Patents
Byzantine fault-tolerant consensus algorithm based on verifiable random function and threshold signature Download PDFInfo
- Publication number
- CN115189871A CN115189871A CN202210806624.7A CN202210806624A CN115189871A CN 115189871 A CN115189871 A CN 115189871A CN 202210806624 A CN202210806624 A CN 202210806624A CN 115189871 A CN115189871 A CN 115189871A
- Authority
- CN
- China
- Prior art keywords
- node
- threshold
- nodes
- block
- signature
- Prior art date
- Legal status (The legal status 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 status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- 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
- H04L9/3255—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 using group based signatures, e.g. ring or threshold signatures
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Hardware Redundancy (AREA)
Abstract
The invention relates to a Byzantine fault-tolerant consensus algorithm based on verifiable random functions and threshold signatures, which comprises the following steps: request phase, pre-Prepare phase, commit phase. The method for selecting the Primary host node by the verifiable random function solves the technical problem that an attacker foresees the result of selecting the Primary host node in advance, can effectively prevent self-adaptive attack, hides the Primary host node and ensures the activity of the system. Through a threshold signature common identification mechanism, when the number of legal signature BackUp nodes collected by any node reaches a threshold value t, a threshold signature can be synthesized and the threshold signature is broadcast, and other BackUp nodes which do not synthesize the threshold signature can stop receiving the voting information of the block and confirm that the block is verified only by verifying one legal threshold signature, so that the technical problems of high cost and poor expansibility are solved, and the technical effects of reducing network pressure and reducing cost are achieved.
Description
Technical Field
The invention relates to a consensus algorithm in the field of block chains, in particular to a Byzantine fault-tolerant consensus algorithm based on a verifiable random function and a threshold signature.
Background
A blockchain is a secure distributed infrastructure and computing specification that utilizes consensus mechanisms to generate and update data, cryptographic techniques to ensure uniqueness of data, and intelligent contracts to ensure smooth execution of contracts. The consensus mechanism is a rule used for achieving consensus in a distributed network lacking central control and coordination, and is a bottom core technology of a block chain, which directly determines the problems of security, consistency, transaction speed, expansibility and the like of the block chain, and thus the consensus mechanism gradually becomes a research hotspot of the block chain. Currently, a Byzantine fault-tolerant algorithm is mainly adopted, but the traditional Byzantine algorithm has the following problems:
1. it is difficult to resist adaptive attacks because the Primary master node identity may be deduced.
2. The high requirement for consensus thus leads to insufficient scalability.
Disclosure of Invention
In order to solve the technical problems that most Byzantine fault-tolerant algorithms are difficult to resist self-adaption attacks and have insufficient expansibility, the invention provides a Byzantine fault-tolerant consensus algorithm based on a verifiable random function and a threshold signature, and the consensus algorithm improves the reliability of selecting the identity of a Primary master node and reduces the network burden caused by transmission.
A Byzantine fault-tolerant consensus algorithm based on verifiable random functions and threshold signatures comprises the following steps:
step 1: in the Request stage, a client side puts forward a transaction Request and sends the transaction Request to all nodes;
step 2: in the Pre-prepare stage, a Primary node is randomly selected through a verifiable random function, the Primary node is used for collecting transaction data, packing blocks, generating the seed of the next proposal and initiating the proposal, and backing up to a Back Up BackUp node when the proposal is sent out, after receiving the transaction request, the Primary node assembles the transaction request into blocks, generates Seednext of the Primary node in the next round through the new blocks, and broadcasts the block, the seed and the Primary node verification information to all Back Up BackUp nodes;
and step 3: in the preparation stage, the BackUp node verifies the received broadcast information, broadcasts the voting information of the BackUp node after the broadcast information is verified to be correct, and collects the voting information of other BackUp nodes;
and 4, step 4: in the Commit stage, in the MaxDelay time, the BackUp node needs to legally verify the received voting information, only the legal voting information is reserved as a threshold signature, if a BackUp node collects enough threshold signatures, the threshold signature is synthesized according to the voting information and the legal threshold signature information is broadcasted, and when other BackUp nodes receive the legal threshold signatures, the blocks are added into a block chain maintained by the BackUp node.
Preferably, the step 2 of randomly selecting the Primary master node through the verifiable random function specifically includes: firstly, a random number r is obtained through a verifiable random function, then the remainder is obtained according to the random number r and the total node number N, whether the obtained value is in a certain range is judged, and the formula is that r% N is less than or equal to 2. And if the value obtained by the summation of the generated random number and the total number of the nodes is less than or equal to 2, the node is the candidate master node.
Preferably, the number f of Byzantine nodes in the N nodes participating in the block chain record should satisfy N ≧ 3f +1, the Byzantine nodes are nodes capable of being maliciously tampered and forged, and when the formula is not satisfied, the security of the system cannot be guaranteed.
Preferably, if the MaxDelay time described above in step 4 is exceeded, the view rotation protocol is initiated.
Preferably, step 2 agrees by using a pre-prepared message, wherein the pre-prepared message has a specific format: < PRE _ PREPARE, v, h, i, hash (msg) > Sigi, seedcurrent, seednext, proof, r, block > where v is the current view index, h is the serial number assigned by the master node to the block of the packing block, i is the index of the current node, hash (msg) is the summary information of msg, where msg is Seedcurrent, seednext, proof, r and block, and < X > Sigi indicates that the information of X is signed by the master node i. The Seedcurrent represents the currently used seed, seednext is used as the seed of the next round of master node election, proof is the proof of a random number r, the proof and r can prove that the current node is the master node, and block is the currently packed block information.
Preferably, the specific format of the voting information in step 3 is < PREPARE, v, n, hash (block) > PartSigi, where < X > PartSigi is that the ith backup node BackUpi signs X with a partial threshold signature private key held by itself, and partial signature messages greater than or equal to a threshold value can be combined to form a threshold signature and generate a confirmation message COMMIT.
Preferably, in step 4, the specific format of the threshold signature message is < COMMIT, v, h, hash) > threshold sig, where threshold sig is an unlocked threshold signature, for a byzantine system including 3f +1 server, at least 2f +1 pieces of confirmation information for block needs to be collected for final confirmation, and when 2f pieces of voting information sent by other copies are collected, the voting information of the threshold signature is added to reach a threshold value t, and the threshold signature is triggered, so that the threshold signature can be obtained, and the PREPARE message is converted into a COMMIT message.
Preferably, the probability that the algorithm can be successfully proposed is
The method comprises the steps that P is the probability that each BackUp network is completely independent and votes by a quorum in a limited time range, n is the BackUp node number, f +1 is the honest node number, k is the node number, which is subjected to binomial distribution, of the legal voting node number received by the BackUp node, and the honest node is the node which cannot be used for tampering and forging data maliciously.
Preferably, the verification in step 3 is to verify whether the sending node is a Primary master node and the validity of the block.
Preferably, the method of the above-mentioned legal verification in step 4 is verfy (threshold sig), specifically, inputting security parameter s, message msg, public key PK and threshold signature threshold sig, and obtaining output judgment values true and false, where true represents that the verification is passed, and false represents that the verification is not passed. The specific expression is verify (s, msg, PK, thresholdSig) → true or false.
In conclusion, the beneficial effects of the invention are as follows:
1. the algorithm selects any next host node for proposal by using the verifiable random function, thereby achieving the purpose of hiding the identity of the host node.
2. Voting is carried out by using a threshold signature mechanism, thereby reducing the network pressure in the processes of consensus achievement, master node selection and view replacement,
3. the system reduces the overhead and improves the expansibility and the DDoS attack resistance.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.
FIG. 1 is a flow chart of a Byzantine fault-tolerant consensus algorithm based on verifiable random functions and threshold signatures in accordance with the present invention;
fig. 2 is a schematic diagram of an algorithm of a byzantine fault-tolerant consensus algorithm based on a verifiable random function and a threshold signature according to the present invention.
Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
A byzantine fault-tolerant consensus algorithm based on verifiable random functions and threshold signatures, please refer to fig. 1-2, comprising the following steps:
step 1: in the Request stage, a client side puts forward a transaction Request and sends the transaction Request to all nodes;
step 2: in the Pre-prepare stage, a Primary node is randomly selected through a verifiable random function, the Primary node is used for collecting transaction data, packing blocks, generating the seed of the next proposal and initiating the proposal, and backing up to a Back Up BackUp node when the proposal is sent out, after receiving the transaction request, the Primary node assembles the transaction request into blocks, generates Seednext of the Primary node in the next round through the new blocks, and broadcasts the block, the seed and the Primary node verification information to all Back Up BackUp nodes;
and step 3: in the stage of Prepare, the BackUp node verifies the received broadcast information, broadcasts the voting information of the BackUp node after the verification is correct, and collects the voting information of other BackUp nodes, wherein the voting information is used for recording block data;
and 4, step 4: in the Commit stage, in the MaxDelay time, the BackUp node needs to legally verify the received voting information, only the legal voting information is reserved as a threshold signature, if a BackUp node collects enough threshold signatures, the threshold signature is synthesized according to the voting information and the legal threshold signature information is broadcasted, and when other BackUp nodes receive the legal threshold signatures, the blocks are added into a block chain maintained by the BackUp node.
Preferably, the step 2 of randomly selecting the Primary master node through the verifiable random function specifically includes: firstly, a random number r is obtained through a verifiable random function, then the remainder is obtained according to the random number r and the total node number N, whether the obtained value is in a certain range is judged, and the formula is that r% N is less than or equal to 2. If the value obtained by adding the generated random number and the total number of the nodes is less than or equal to 2, the node is a candidate master node, and the specific embodiment is as follows: if the proposal of the current main node reaches final consensus, v = (v + 1)% N of the BackUp node, then the BackUp node is calculated according to a verifiable random function to judge whether the BackUp node is a main node candidate of the next round, a random number r is obtained according to the verifiable random function, and the solving process is r = VRF ((Seed) () next V, h, count), SK), where (Seednext, v, h, count) is used as the seed of the verifiable random function, where count is a counter, the initial value is 0, and SK is the private key of the node itself. And then, the remainder is obtained according to the random number r and the total number N, and whether the obtained value is in a certain range or not is judged, wherein the formula is that r% N is less than or equal to 2. And if the value obtained by the summation of the generated random number and the total number of the nodes is less than or equal to 2, the node is the candidate master node. And if the candidate master node is found in one round of election, the random number r is continuously solved according to the VRF by + + count, and then the subsequent operation is carried out. If one node BackUpi alternative node is a candidate main node, sending a message<SELECT_LEADER，v，h，count，r，PK>Sigi, the other nodes firstly judge the accuracy of the message according to the received SELECT _ LEADER message, if the message is correct, the message is sorted from small to large according to the value of r% N, if a plurality of complementation values are equal, the message is sorted from small to large according to hash (r), then the minimum value is taken as the master node to carry out threshold signature voting, and when the voting number of a certain node exceeds a threshold value, the node is elected as the master node of the next round. The method solves the technical problem that the next Primary master node is easy to calculate, and has the technical effect of improving the algorithm security.
Preferably, the number f of byzantine nodes in the N nodes participating in block chain recording should satisfy N ≧ 3f +1, the above-mentioned byzantine node is a node capable of maliciously tampering and forging data, and when the above-mentioned formula is not satisfied, the security of the system cannot be guaranteed, the above-mentioned formula is limited because: the total number of nodes is set to be 3f +1, wherein the number of Byzantine nodes is at most f, and the number of honest nodes is at least 2f +1. In the consensus phase, the threshold value of the threshold signature algorithm set by the invention is 2f +1. This ensures that consensus is achieved each time, since t-f = f +1, the number of honest copies is at least f +1, which is 1 more than if the number of byzantine nodes were the largest. And under the condition that the number of Byzantine nodes is the maximum value f, the proportion of the votes of all honest nodes to all the honest nodes exceeds half number (f + 1)/(2f + 1) >1/2, and the arrangement has the technical effects of ensuring the stability of a system and improving the safety.
Preferably, if the MaxDelay time in step 4 is exceeded, a view rotation protocol is started, and the specific embodiment of the view rotation protocol is as follows:
step 1: if the BackUpi backup node is not the Primary node and the latency is exhausted, then the View rotation protocol is initiated, first incrementing the VIEW number by 1, and then sending the View _ CHANGEi message. VIEW _ CHANGEi refers to a VIEW rotation message sent by a BackUpi backup node, and the specific content of the VIEW rotation message is<VIEW_CHANGE，v new ，h，PartSig i ，ThresholdSig>sig i Where v _ new = (v + 1)% N, N is the total number of BackUp nodes; h refers to the height of the current block chain; partSigi is a partial threshold signature of the current BackUpi backup node on view conversion; thresholdSig is the threshold signature received by BackUpi backup node in View v.
Step 2: if the BackUpj backup node receives a legal VIEW rotation message for a Primary node for the first time, the current VIEW of the BackUpj backup node is added with 1, and then the VIEW rotation message VIEWCHANGEj is broadcasted.
And step 3: if the backup node is the Primary node of the next round, the backup node receives the view conversion message, counts the PartSig and ThresholdSig information in the view conversion message, and processes the view conversion message according to the following three conditions:
case 1: if the view rotation information collected by the BackUpk backup node contains legal ThresholdSig information, the BackUpk backup node directly broadcasts a NEW _ VIEWWk message indicating that the NEW view rotation is successful. NEW _ VIEWK represents a message from a BackUpk backup node to send a NEW VIEW, with specific content of < NEW _ VIEW, v new ，h，msg.ThresholdSig＞Sig k ；
Case 2: if the number of partial signatures PartSig in the same view rotation information collected by the BackUpk backup node exceeds a threshold value t, synthesizing a threshold signature ThresholdSig, and broadcasting a message NEW _ VIEWK of successful view conversion;
case 3: if the wait time for the BackUpk backup node to collect information is exhausted and the threshold signature ThresholdSig of view rotation is not obtained yet, the BackUpk backup node broadcasts a NEW _ LEADER message. The specific content of the NEW _ LEADER message is < NEW _ LEADER, v new ，h，i，，hash(block old )，hash(msg)＞Sig k ，Seed current ，Seed next ，proof，r，block new ＞Sig k Wherein hash (blockld) and digest information of the block which is not agreed with the previous round of view, blocknew represents the new block packed by the backup node, and the rest of meanings are kept together with the PRE _ PREPARE message. It can be proven by this message that it is a new Primary master node and the view has been changed.
And 4, step 4: if the backup p node of the BackU receives the NEW _ VIEW message, the VIEW replacement is considered to be completed; and if the Back Up node receives the NEW _ LEADER message, voting the NEW proposal blocknew contained in the NEW _ LEADER message, wherein the specific process of the voting is consistent with the algorithm flow of VRF _ TS _ BFT.
The technical problems that the Primary host node issues false information for the Byzantine node, the Primary host node cannot carry out normal proposal due to crash, and the BackUp node waits for receiving the execution message for exceeding the time limit are solved through the setting of the embodiment, and the technical effect of improving the stability of the algorithm is achieved.
Preferably, step 2 agrees by a pre-prepared message, and the format of the pre-prepared message is as follows: < PRE _ PREPARE, v, h, i, hash (msg) > Sigi, seedcurrent, seednext, proof, r, block > where v is the current view index, h is the serial number assigned by the master node to the block of the packing block, i is the index of the current node, hash (msg) is the summary information of msg, where msg is Seedcurrent, seednext, proof, r and block, and < X > Sigi indicates that the information of X is signed by the master node i. Seedcurrent represents the currently used seed, seednext is used as the seed for the next round of master node election, proof is the proof of a random number r, the proof and the proof can prove that the current node is the master node and block is the block information of the current package through proof and r, and the technical problem of communication of each node in the Pre-prepare stage is solved through the limitation on the Pre-prepare information.
Preferably, the specific format of the voting information in step 3 is < PREPARE, v, n, hash (block) > PartSigi, where < X > PartSigi is that the ith backup node BackUp signs X with a part of threshold signature private key held by itself, and part of signature messages greater than or equal to a threshold value can be combined to generate a threshold signature and generate a confirmation message COMMIT, and the technical problem of difficulty in verifying the threshold signature is solved by limiting the specific format of the voting information.
Preferably, in step 4, the specific format of the threshold signature message is < COMMIT, v, h, hash) > threshold sig, where threshold sig is an unlocked threshold signature, for a byzantine system containing 3f +1 server, at least 2f +1 pieces of confirmation information for block needs to be collected for final confirmation, after 2f pieces of voting information sent by other copies are collected, the threshold signature is triggered by adding the voting information of itself to reach a threshold value t, so that the threshold signature can be obtained, the PREPARE message is converted into the COMMIT message, and communication is performed on the premise of transmitting fewer characters by limiting the threshold signature message, so as to solve the technical problem of too long voting time.
Preferably, the probability that the algorithm can successfully propose is
Wherein, P is the probability that each BackUp network is completely independent and votes by a quorum in a limited time range, n is the BackUp node number of BackUp, f +1 is the honest node number, k is the node number that the legal voting node number received by the BackUp node of BackUp obeys binomial distribution, the honest node is the node which can not be maliciously tampered and forged data, and the probability is deduced as follows:
assuming that each BackUp node is completely independent and the probability of receiving the quorum vote in a limited time range is p, in a consensus algorithm network consisting of n BackUp nodes, the probability of receiving the quorum vote by k BackUp nodes obeys two-term distribution, and the algorithm is as follows:
in the PBFT consensus algorithm, because each node receives at least 2f +1 confirmation messages to ensure that the proposal passes through in the two phases, the probability of success of the proposal in each phase is:
in the consensus algorithm, the proposal can be guaranteed to pass through only needing any node in the Prepare stage to collect 2f +1 pieces of confirmation information. In the best case, if all the received PartSig information is sent by the honest nodes, only the signature information sent by the f +1 honest nodes needs to be collected by one node, so that the threshold signature ThresholdSig can be obtained, and the proposal is passed. Therefore, the probability of success of the proposal is as follows:
preferably, the verification in step 3 is to verify whether the sending node is a Primary node and the validity of the block, and the technical problem that the subsequent voting encounters illegal voting information is solved by verifying the validity of the block in advance, so that the technical effects of improving the process and improving the system stability are achieved.
Preferably, the method of the above-mentioned legal verification in step 4 is verfy (threshold sig), specifically, inputting security parameter s, message msg, public key PK and threshold signature threshold sig, and obtaining output judgment values true and false, where true represents that the verification is passed, and false represents that the verification is not passed. The specific expression is verify (s, msg, PK, thresholdSig) → true or false. By the verification of the voting information, the technical problems of error and malicious tampering of the threshold signature are solved, and the technical effect of improving the system safety is achieved.
In summary, the method for verifying random function selection of Primary master node in the invention solves the technical problem that an attacker foresees the Primary master node selection result in advance, can effectively prevent self-adaptive attack, hides the Primary master node, and ensures the activity of the system. Through a threshold signature consensus mechanism, when the number of legal signatures collected by any node reaches a threshold value t, the threshold signature can be synthesized and broadcasted, and other people who do not synthesize the threshold signature can stop receiving the voting information of the block only by verifying one legal threshold signature and confirm that the block is verified, so that the technical problems of high cost and poor expansibility are solved, and the technical effects of reducing network pressure and overhead are achieved.
And those not described in detail in this specification are well within the skill of the art.
It is noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus.
Claims (10)
1. A Byzantine fault-tolerant consensus algorithm based on verifiable random functions and threshold signatures, comprising the steps of:
step 1: in the Request stage, a client side puts forward a transaction Request and sends the transaction Request to all nodes;
step 2: in the Pre-prepare stage, a Primary node is randomly selected through a verifiable random function, the Primary node is used for collecting transaction data, packing blocks, generating the seed of the next proposal and initiating the proposal, and backing up to a BackUp node when the proposal is sent out, after receiving the transaction request, the Primary node assembles the transaction request into blocks, generates Seednext of the Primary node in the next round through the new blocks, and broadcasts the block, the seed and the Primary node verification information to all the BackUp nodes;
and step 3: in the stage of Prepare, the BackUp node verifies the received broadcast information, broadcasts the voting information of the BackUp node after the broadcast information is verified to be correct, and collects the voting information of other BackUp nodes;
and 4, step 4: in the Commit stage, in the MaxDelay time, the BackUp node needs to legally verify the received voting information, only the legal voting information is reserved as a threshold signature, if a certain BackUp node collects enough threshold signatures, a threshold signature is synthesized according to the voting information and the legal threshold signature information is broadcasted, and when other BackUp nodes receive the legal threshold signatures, the block is added into a block chain maintained by the BackUp node.
2. The Byzantine fault-tolerant consensus algorithm based on a verifiable random function and a threshold signature as claimed in claim 1, wherein the step 2 of randomly selecting a Primary Master node through the verifiable random function specifically comprises: firstly, a random number r is obtained through a verifiable random function, then the remainder is obtained according to the random number r and the total node number N, whether the obtained value is in a certain range is judged, and the formula is that r% N is less than or equal to 2. And if the value obtained by the summation of the generated random number and the total number of the nodes is less than or equal to 2, the node is the candidate master node.
3. The Byzantine fault-tolerant consensus algorithm based on the verifiable random function and the threshold signature as claimed in claim 1, wherein the number f of Byzantine nodes in N nodes participating in the block chain record should satisfy N ≧ 3f +1, the Byzantine nodes are nodes capable of tampering and forging data maliciously, and the security of the system cannot be guaranteed when the formula is not satisfied.
4. The Byzantine fault-tolerant consensus algorithm based on a verifiable random function and a threshold signature as claimed in claim 1, wherein if the MaxDelay time of step 4 is exceeded, then a view rotation protocol is initiated.
5. The Byzantine fault-tolerant consensus algorithm based on verifiable random functions and threshold signatures as claimed in claim 2, wherein step 2 agrees by pre-prepared messages, the pre-prepared messages being specifically formatted as: < PRE _ PREPARE, v, h, i, hash (msg) > Sigi, seedcurrent, seednext, proof, r, block > where v is the current view index, h is the serial number assigned by the master node to the block of the packing block, i is the index of the current node, hash (msg) is the summary information of msg, where msg is Seedcurrent, seednext, proof, r and block, and < X > Sigi indicates that the information of X is signed by the master node i. The Seedcurrent represents the currently used seed, seednext is used as the seed of the next round of master node election, proof is the proof of a random number r, the proof and r can prove that the current node is the master node, and block is the currently packed block information.
6. The Byzantine fault-tolerant consensus algorithm based on a verifiable random function and a threshold signature as claimed in claim 1, wherein the voting information in step 3 is specifically formatted as < PREPARE, v, n, hash (block) > PartSigi, where < X > PartSigi is that the ith backup node BackUpi signs X with a threshold signature private key of a part held by itself, and partial signature messages greater than or equal to a threshold value can combine MIT threshold signatures and generate a confirmation message COM.
7. The Byzantine fault-tolerant consensus algorithm based on verifiable random functions and threshold signatures as claimed in claim 3, wherein the specific format of the threshold signature message in step 4 is < COMMIT, v, h, hash (block) > ThresholdSig, where ThresholdSig is the unlocked threshold signature, for a Byzantine system containing 3f +1 servers, at least 2f +1 pieces of confirmation information for block need to be collected for final confirmation, and when 2f pieces of voting information sent by other copies are collected, the threshold signature is triggered by adding own voting information to reach the threshold value t, so that a signature can be obtained, and the PREMIT message is converted into a COMMIT message.
8. The Byzantine fault-tolerant consensus algorithm based on a verifiable random function and a threshold signature as claimed in claim 1, wherein the probability that the algorithm will successfully propose is
The method comprises the steps that P is the probability that each BackUp network is completely independent and receives quorum voting in a limited time range, n is the number of BackUp nodes, f +1 is the number of honest nodes, k is the number of nodes, obeying binomial distribution, of the number of legal voting nodes received by the BackUp nodes, and the honest nodes are nodes which cannot be maliciously tampered and forged.
9. The Byzantine fault-tolerant consensus algorithm based on verifiable random function and threshold signature as claimed in claim 1, wherein the verification in step 3 is to verify whether the sending node is a Primary Master node and the validity of the block.
10. The Byzantine fault-tolerant consensus algorithm based on verifiable random functions and threshold signatures as claimed in claim 7, wherein the method of legal verification in step 4 is verfy (threshold Sig), specifically inputting security parameters s, message msg, public key PK and threshold signature threshold Sig, to obtain output decision values true and false, where true indicates that verification is passed and false indicates that verification is not passed. The specific expression is verify (s, msg, PK, thresholdSig) → true or false.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210806624.7A CN115189871A (en) | 2022-07-08 | 2022-07-08 | Byzantine fault-tolerant consensus algorithm based on verifiable random function and threshold signature |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210806624.7A CN115189871A (en) | 2022-07-08 | 2022-07-08 | Byzantine fault-tolerant consensus algorithm based on verifiable random function and threshold signature |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN115189871A true CN115189871A (en) | 2022-10-14 |
Family
ID=83516404
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210806624.7A Pending CN115189871A (en) | 2022-07-08 | 2022-07-08 | Byzantine fault-tolerant consensus algorithm based on verifiable random function and threshold signature |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115189871A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116684426A (en) * | 2023-08-03 | 2023-09-01 | 南方科技大学 | Task processing method based on Bayesian consensus protocol |
-
2022
- 2022-07-08 CN CN202210806624.7A patent/CN115189871A/en active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116684426A (en) * | 2023-08-03 | 2023-09-01 | 南方科技大学 | Task processing method based on Bayesian consensus protocol |
| CN116684426B (en) * | 2023-08-03 | 2024-01-09 | 南方科技大学 | Task processing method based on Bayesian consensus protocol |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110289966B (en) | Byzantine fault tolerance-based anti-adaptive attack union chain consensus method | |
| CN110796547A (en) | Improved practical Byzantine fault-tolerant system based on alliance block chain | |
| CN112257095B (en) | Method for selecting alliance chain consensus node | |
| CN109379343B (en) | Heterogeneous consensus method of block chains and terminal | |
| CN113301114B (en) | Block chain consensus node selection method and device, computer equipment and storage medium | |
| CN111935207A (en) | Block chain system consensus method based on improved C4.5 algorithm | |
| CN112468255B (en) | Block link point time synchronization method based on network consensus and VRF algorithm | |
| CN111182510A (en) | Industrial Internet of things node consensus method based on block chain | |
| CN114862397B (en) | Double-decoupling block chain distributed method based on double-chain structure | |
| CN115189871A (en) | Byzantine fault-tolerant consensus algorithm based on verifiable random function and threshold signature | |
| CN114463009B (en) | Method for improving transaction security of large-scale energy nodes | |
| CN112395113A (en) | Practical Byzantine fault-tolerant consensus method and device and readable storage medium | |
| CN112769936B (en) | POVT consensus algorithm based on voting and credit mechanism | |
| CN114528565A (en) | Efficient sensitive data uplink algorithm based on block chain | |
| CN116527684B (en) | Multi-chain information interaction method based on 1+1+N relay consensus committee | |
| CN109274674B (en) | Block chain heterogeneous consensus method with high security and terminal | |
| CN115834512A (en) | Data sharing method, system, electronic equipment and storage medium | |
| CN113946829B (en) | Block chain-based Internet of vehicles distributed trust system | |
| CN116055579A (en) | Multi-alliance chain crossing method | |
| CN115643047A (en) | Block chain identity authentication method based on honest rewards | |
| CN110443713B (en) | Method and system for improving block chain transaction efficiency | |
| CN112116461A (en) | Block chain and consensus method thereof | |
| An et al. | Research on Byzantine Fault Tolerant algorithm based on Node Weights | |
| CN112583584B (en) | Service monitoring system and method based on random number | |
| CN115334088B (en) | Domain name system data synchronization method, device and system based on blockchain |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |