CN114205092B - Optimistic Bayesian-preemption fault-tolerant consensus method without rollback - Google Patents

Optimistic Bayesian-preemption fault-tolerant consensus method without rollback Download PDF

Info

Publication number
CN114205092B
CN114205092B CN202111452583.8A CN202111452583A CN114205092B CN 114205092 B CN114205092 B CN 114205092B CN 202111452583 A CN202111452583 A CN 202111452583A CN 114205092 B CN114205092 B CN 114205092B
Authority
CN
China
Prior art keywords
information
node
master node
request
nodes
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.)
Active
Application number
CN202111452583.8A
Other languages
Chinese (zh)
Other versions
CN114205092A (en
Inventor
刘健
芦浩
任奎
杨国正
臧铖
陈嘉俊
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Zhejiang University ZJU
China Zheshang Bank Co Ltd
Original Assignee
Zhejiang University ZJU
China Zheshang Bank Co Ltd
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 Zhejiang University ZJU, China Zheshang Bank Co Ltd filed Critical Zhejiang University ZJU
Priority to CN202111452583.8A priority Critical patent/CN114205092B/en
Publication of CN114205092A publication Critical patent/CN114205092A/en
Application granted granted Critical
Publication of CN114205092B publication Critical patent/CN114205092B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

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/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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/46—Secure multiparty computation, e.g. millionaire problem
    • H04L2209/463—Electronic voting

Abstract

The invention discloses an optimistic Bayesian fault-tolerant consensus method without rollback, which comprises the steps that a main node initiates proposal, all nodes vote on the proposal for the first time, the main node judges whether the condition of a system is an optimistic condition according to the voting result of the first time, and different consensus methods are adopted to consensus the proposal under the optimistic and non-optimistic conditions; all nodes verify proposal requests sent by the master node and execute corresponding operations according to the message types; in this process, if the node finds that the master node has a bayer pattern, a view change request is broadcast to elect a new master node. The invention can be applied to a consensus layer in a blockchain application as a consensus protocol, and has the advantages of simple implementation method, strong universality, effectively reduced bandwidth consumption, high efficiency, high robustness and the like.

Description

Optimistic Bayesian-preemption fault-tolerant consensus method without rollback
Technical Field
The invention relates to the technical field of blockchains, in particular to an optimistic Bayesian fault tolerance (Byzantine Fault Tolerance, BFT) consensus method without rollback.
Background
The practical Bayer fault-tolerant consensus algorithm is proposed by migel-Castro (Miguel Castro) and Barbara-riskov (Barbara Liskov) in 1999, and solves the problem that the original Bayer fault-tolerant algorithm is not efficient.
The aggregated signature technology can combine a plurality of signatures into one signature, and only one verification operation is needed for the aggregated signature. This feature can reduce the complexity of communication to some extent, but two rounds of voting are still required to achieve consensus among the nodes.
The speculative Bayesian fault-tolerant consensus algorithm was proposed by Hirsheng-Kotera (Ramakrishna Kotla) in Luo Make in 2007, which uses an aggregate signature technique to effectively reduce the communication complexity and optimize the algorithm for the non-Bayesian error scenario, speculatively adopts a simpler consensus algorithm to quickly reach consensus without always performing two rounds of voting, but when the quick consensus fails, a rollback operation is required on the state of the system.
The existing Bayesian fault-tolerant algorithm either needs two rounds of voting or adopts a method of speculative execution to reduce the number of voting rounds, so that the problem of state rollback operation is introduced, and how to improve the efficiency of the consensus process is still a problem to be solved.
Disclosure of Invention
The invention aims to provide an optimistic Bayesian fault-tolerant consensus method without rollback, which aims to overcome the defects of the prior art.
The aim of the invention is realized by the following technical scheme: an optimistic Bayesian-preemptive fault-tolerant consensus method without rollback, comprising the steps of:
(1) Client C initiates a transaction in the blockchain system and sends a request m=<REQUEST,TX,σ c >,σ c ←Sign(<REQUEST,TX>) For master node S p While client C sets a timer, whereSigma represents a signature, subscript represents a signer, sign () is a signature function, TX is a transaction requested to be performed by the client;
master node S p Receiving request M and validating sigma c After signing, broadcast<PRE-PREPARE,M,sn,v,σ p >,σ p ←Sign(<H(M),sn,v>) To all nodes S i I=1, …, (3f+1); the node only processes the information of which the view number is consistent with the view number where the node is located, and the master node S p Setting a timer and waiting for voting information from the node. Wherein (3f+1) is the number of nodes in the blockchain system, including at most f Bayesian nodes and at least (2f+1) correct nodes; v is node S p The view number of the view where sn is the number allocated to the request M by the master node;
(2) Node S i Receiving the signal from step (1)<PRE-PREPARE,M,sn,v,σ p >Verify sigma p Then vote and send it<PREPARE,H(M),sn,v,σ i >,σ i ←Sign(<H(M),sn,v>) For master node S p ；
(3) Master node S p Judging whether the voting information is optimistic according to the quantity of the received voting information and broadcasting information to other nodes, wherein if the master node S p If the number of the received consistent voting information is (3f+1), the master node S is optimistic p The number of the received consistent voting information is (2f+1) to 3f, and the situation is general;
(4) If the step (3) is determined to be the general case node S i According to the master node S p The broadcast information is voted for the second round, and if optimistic, the node S i According to the master node S p The broadcasted information directly executes the request and feeds back the result to the client C; master node S after the second round of voting p Judging whether the request can be executed or not according to the voting result, if so, broadcasting information to other nodes, and the other nodes according to the master node S p The broadcasted information directly performs the request and feeds back the result to the client C.
In the execution process of the steps (1) - (4), if the node finds that the master node has the Bayesian behavior, the node broadcasts the view change request information to elect a new master node, and the subsequent consensus is completed under the new master node.
Further, said step (3) is realized by the sub-steps of:
(3.1) judging the system state: master node S p Before the timer expires, the system state is considered to be optimistic once consistent voting information from (3f+1) different node signatures is received; if the master node S p Only consistent voting information of (2f+1) to 3f different node signatures is received at the end of the timer<PREPARE,H(M),sn,v,σ i >The system state is considered to be a general case; wherein the consistent voting information is H (M), sn, v are the same and the signature is correct<PREPARE,H(M),sn,v,σ i >。
(3.2) Master node S p Tells other nodes according to the system state broadcast information: under optimistic conditions, the master node S p Aggregating the received (3f+1) different node signaturesAggre () is a signature aggregation function and broadcasts informationTo all nodes S i The method comprises the steps of carrying out a first treatment on the surface of the In general, a master node S p Aggregating (2f+1) of the received (2f+1) to 3f different node signatures +.>And broadcast information +.> To all nodes S i 。
Further, the step (4) specifically comprises:
if node S i Receiving the master node S in step (3.2) p Transmitted informationDirectly executing the corresponding request after verifying the signature, and transmitting<REPLY,res,sn,v,σ i ”>,σ i ”←Sign(<H (res), sn, v) to the client C, wherein res is the result of executing the request;
if node S i Receiving the master node S in step (3.2) p Transmitted informationAfter verifying the signature, carrying out a second round of voting on the corresponding request, and sending<COMMIT,H(M),sn,v,σ i ’>,σ i ’←Sign(<H(M),sn,v,COMMIT>) For master node S p ；
Master node S p Upon receipt of the transmitted (2f+1) identical voting information signed by the different nodes<COMMIT,H(M),sn,v,σ i ’>The request is considered to be executable by the master node S p Aggregating (2f+1) different node signaturesAnd broadcast information +.>To all nodes S i ；
If node S i Receiving the master node S p Transmitted byDirectly executing the request after verifying the two aggregation signatures, and transmitting<REPLY,res,sn,v,σ i ”>，σ i ”←Sign(<H(res),sn,v>) To client C.
Further, if the node finds that the master node has a bayer pattern, broadcasting view change request information to elect a new master node is implemented by the following sub-steps:
(a1) Detecting the Bayesian behavior: if client C does not receive consistent result information of at least (f+1) different node signatures within a prescribed time periodBroadcast information m=<REQUEST,TX,σ c >To all nodes S i When node S i Starting a timer after receiving the information, if the timer is finished before S i Without receipt of the master node S p Any information sent corresponding to the request M or in the verification S p Detecting Bayesian behavior in signing of transmitted information S i Broadcasting view change request information<REQ-VIEW-CHANGE,v,σ rv i >,σ rv i ζ (REQ-VIEW-CHANGE, v) to request election of a new master node;
(a2) Node S i Upon receipt of consistent view change request information signed by (f+1) different nodes<REQ-VIEW-CHANGE,v,σ rv i >Broadcast a message carrying a local message log L<VIEW-CHANGE,v+1,L,σ L i >,σ L i ←Sign(<H(L)>) Indicating that a new master node is ready to be elected; wherein L contains all PRE-PREPARE, PREPARED, COMMITTED information received by the node;
(a3) Constructing a new message log: node S i Upon receipt of a consistent of (2f+1) different node signatures<VIEW-CHANGE,v+1,L,σ L i >The node constructs a new message log based on the received (2f+1) message logs and the following rules
a. If the COMMITTED information broadcasted in the step (4) or the step (3.2) exists in the message log, adding PRE-PREPARE information corresponding to the informationAnd marks it as "to be executed";
b. if there are (f+1) M, sn, v in the message log, and the PRE-PREPARE information broadcast in step (1) with the same sn and the correct signature exists, and the PRE-PREPARE information broadcast in step (3.2) with the same sn and the correct signature exists, but the corresponding PRE-PREPARE information is different from the (f+1) PRE-PREPARE information, selecting to have the view numberThe PRE-PREPARE information corresponding to the larger information is added toAnd marks it as "to vote";
c. if there are only (f+1) identical PRE-PREPARE information broadcast in step (1) with correct signature in the message log, adding the PRE-PREPARE information to the message logAnd marks it as "to vote";
d. if there is only PREPARE information broadcasted in the step (3.2) with correct signature in the message log, adding PRE-PREPARE information corresponding to the information to the message logAnd marks it as "to vote";
the node which is completed by the first construction is used as a new master node S p’ And broadcast To all nodes S i ；
(a4) View replacement: if node S i Receiving the message broadcast in step (a 3)Verify signature and use the structure->Method verification of->After that, the message log is +_ according to the following rules>Processing the information in the process:
a. for PRE-PREPARE information marked as 'to be executed', directly executing the corresponding transaction request and sending<REPLY,res,sn,v+1,σ i ”’>,σ i ”’←Sign(<H (res), sn, v+1) to the client C, where res is the result of executing the request;
b. for PRE-PREPARE information marked as 'to-be-voted', changing to a new view v+1, voting for the corresponding request for the second round, and sending<COMMIT,H(M),sn,v+1,σ i ’>,σ i ’←Sign(<H(M),sn,v+1,COMMIT>) For master node S p’ The master node continues to judge whether the request can be executed or not according to the second round of voting, if the request can be broadcasted, other nodes are informed of the information, and the other nodes are according to the master node S p The broadcasted information directly performs the request and feeds back the result to the client C.
The invention has the advantages that when the system does not have the Bayesian behavior, namely, under the optimistic condition, the nodes can reach consensus by only carrying out one round of voting, thereby effectively reducing the confirmation delay, greatly reducing the information quantity in the system and obviously improving the throughput. And the state rollback is not needed under the general condition, the second round of voting is only needed on the basis of the first round of voting, the implementation method is simple, errors are not easy to occur, and the code quality can be ensured.
Drawings
Fig. 1 is a communication mode of the invention under optimistic conditions.
Fig. 2 is a communication mode of the invention in a general case.
Detailed Description
The present invention will be described in detail below with reference to the accompanying drawings.
The invention discloses an optimistic Bayesian-busy-family fault-tolerant consensus method without rollback, which comprises the following steps:
(1) The master node broadcasts the proposal.
Let (3f+1) nodes in the system, including up to f Bayesian nodes and at least (2f+1) correct nodes, sign messages using BLS (Boneh-Lynn-shack) signature algorithm, realThe signature is now aggregated. Client C sends a request m=<REQUEST,TX,σ c >(wherein sigma c ←Sign(<REQUEST,TX>) Is signature information of the client, sign () is signature function, TX is a transaction requested to be performed by the client) to the master node S p At the same time, the client C sets a timer (the size of the timer can be set to an appropriate value according to the network conditions), and the master node S p Receiving M and verifying sigma c After that, broadcast<PRE-PREPARE,M,sn,v,σ p >To all nodes S i (i may be equal to p, i.e. broadcast to all nodes including itself), where σ p ←Sign(<H(M),sn,v>) Is the master node S p While master node S p Setting a timer (the size of the timer can be set to an appropriate value according to the network conditions) and waiting for voting information sent by the node (where v is the node S p The view number of the view where the node is located, sn is the number allocated to the request M by the master node, H () is a hash function, and all nodes perform view number judgment on each received message, and the node only processes the information that the view number is consistent with the view number where the node is located).
(2) The first round of voting (for use in step (3)).
Node S i Receiving the signal from step (1)<PRE-PREPARE,M,sn,v,σ p >Verify sigma p Then vote and send it<PREPARE,H(M),sn,v,σ i >For master node S p (wherein sigma i ←Sign(<H(M),sn,v>) Is node S i Is provided) signature information.
(3) Master node S p Judging whether the voting information is optimistic according to the quantity of the received voting information and broadcasting information to other nodes.
This step is the core of the present invention and is divided into the following sub-steps.
And (3.1) judging the system state.
After the first round of voting, the master node receives voting information (including itself) sent by the node within a prescribed time. Master node S p Upon receipt of consistent voting information from (3f+1) different node signatures before the timer expires<PREPARE,H(M),sn,v,σ i >(requirement forAnd the corresponding H (M), sn, v are the same, and the signature is correct), the system state is considered to be an optimistic situation. If the master node S p No consistent voting information from (3f+1) but (2f+1) to 3f different node signatures is received at the end of the timer<PREPARE,H(M),sn,v,σ i >(the corresponding H (M), sn, v are required to be the same and the signature is correct), the system state is considered to be the general case. If the master node S p Receipt of consistent voting information of less than (2f+1) different node signatures at the end of the timer<PREPARE,H(M),sn,v,σ i >No processing is performed.
(3.2) the master node performing a corresponding operation according to the system state.
Under optimistic conditions, the master node S p Aggregating signatures({σ i (3f+1) signature, aggre () is a signature aggregation function), and broadcasting information +.>To all nodes S i . In general, a master node S p Aggregating signatures +.>({σ i (2f+1) out of (2f+1) to 3f signatures, aggre () is a signature aggregation function), and broadcasting information +.> To all nodes S i 。
(4) And (3) judging to perform voting or executing requests of the second round according to the information sent in the step (3).
This step is the core of the present invention, and is specifically as follows:
if node S i Receiving the master node S in step (3.2) p Transmitted letterRestDirectly executing the corresponding request after verifying the signature and sending<REPLY,res,sn,v,σ i ”>To client C (wherein σ i ”←Sign(<H (res), sn, v), res being the result of executing the request), as shown in fig. 1.
If node S i Receiving the master node S in step (3.2) p Transmitted informationAfter verifying the signature, a second round of voting is performed on the corresponding request, as shown in fig. 2, and the transmission is performed<COMMIT,H(M),sn,v,σ i ’>(wherein sigma i ’←Sign(<H(M),sn,v,COMMIT>) To the master node S) p . The master node judges whether the request can be executed after the second round of voting:
master node S p Upon receipt of consistent second round voting information of (2f+1) different node signatures<COMMIT,H(M),sn,v,σ i ’>The request is considered to be executable by the master node S p Aggregating signatures({σ i ' is a set of (2f+1) signatures) and broadcasts information +.>To all nodes S i (/>Is an aggregate signature in the PREPARED information corresponding to step (3.2).
If node S i Receiving the master node S p Transmitted byDirectly execute the request after verifying the signature and send<REPLY,res,sn,v,σ i ”>To client C (wherein σ i ”←Sign(<H(res),sn, v), res is the result of executing the request).
In the whole process, if the node finds that the master node has the Bayesian behavior, the view change request information is broadcasted to elect a new master node.
This step is the core of the present invention and is divided into the following sub-steps.
(a1) The bayer behaviour is detected.
If client C does not receive consistent information of at least (f+1) different node signatures within a prescribed time<REPLY,res,sn,v,σ i ”>Broadcast information m=<REQUEST,TX,σ c >To all nodes S i When node S i Starting a timer after receiving the information, and if the timer is finished, S i Without receipt of the master node S p Any information sent to correspond to the request, the current master node S is considered p There is a Bayesian behavior, S i Broadcasting view change request information<REQ-VIEW-CHANGE,v,σ i >To request election of a new master node. If in verification S p The transmitted information is signed to find out the Bayesian behavior, i.e. the verification is not passed, and is transmitted<REQ-VIEW-CHANGE,v,σ rv i >(wherein v is node S i Current view number, σ rv i ←Sign(<REQ-VIEW-CHANGE,v>))。
(a2) Node S i Upon receipt of consistent view change request information signed by (f+1) different nodes<REQ-VIEW-CHANGE,v,σ rv i >Broadcast a message carrying a local message log L<VIEW-CHANGE,v+1,L,σ L i >Indicating that it is ready to elect a new master node (where L contains all PRE-PREPARE, PREPARED, COMMITTED information, σ, received by the node L i ←Sign(<H(L)>))。
(a3) A message log is constructed.
Node S i Upon receipt of a consistent of (2f+1) different node signatures<VIEW-CHANGE,v+1,L,σ L i >The node constructs a new message log based on the received (2f+1) message logs and the following rules
a. If the COMMITTED information broadcasted in the step (4) or the step (3.2) exists in the message log, adding PRE-PREPARE information corresponding to the informationAnd marks it as "to be executed".
b. If there are (f+1) identical PRE-PREPARE information (corresponding to M, sn, v are the same) broadcasted in the step (1) with correct signature in the message log, and there are PRE-PREPARE information with the same sn and correct signature broadcasted in the step (3.2) at the same time, but the corresponding PRE-PREPARE information is different from the (f+1) identical PRE-PREPARE information, the PRE-PREPARE information corresponding to the information with larger view number is selected to be added toAnd marks it as "to vote".
c. If there are only (f+1) identical PRE-PREPARE information broadcast in step (1) with correct signature in the message log, adding the PRE-PREPARE information to the message logAnd marks it as "to vote".
d. If there is only PREPARE information broadcasted in the step (3.2) with correct signature in the message log, adding PRE-PREPARE information corresponding to the information to the message logAnd marks it as "to vote".
The node which is completed by the first construction is used as a new master node S p’ And broadcastTo all nodes S i (wherein->
(a4) View replacement.
If node S i Receiving the message broadcast in step (a 3)Verify signature and use the structure->Method verification of->After that, the message log is +_ according to the following rules>Processing the information in the process:
a. for PRE-PREPARE information marked as 'to be executed', directly executing the corresponding transaction request and sending<REPLY,res,sn,v+1,σ i ”’>For client C, where σ i ”’←Sign(<H(res),sn,v+1>) Res is the result of executing the request).
b. For PRE-PREPARE information marked as 'to-be-voted', changing to a new view v+1, voting for the corresponding request for the second round, and sending<COMMIT,H(M),sn,v+1,σ i ’>For master node S p’ (wherein sigma i ’←Sign(<H(M),sn,v+1,COMMIT>) Then the master node judges whether the request can be executed after the second round of voting, if so, the other nodes are informed of broadcasting information, and the other nodes are according to the master node S p The broadcasted information directly performs the request and feeds back the result to the client C.
Safety certification (Safety)
To prove the security of the method, namely, prove: if the correct node S i Executing the transaction request TX with the number sn in view v, there will not be a correct node S j The transaction request TX 'different from TX is performed in view v'. Gtoreq.v with the number sn.
Assume correct node S i In view v, the transaction request TX is executed with number sn, then S i The communication information broadcasted in step (4) or step (3.2) of the embodiment may be received:
if S i Broadcast in view v receipt step (3.2)Then (3f+1) nodes receive PRE-PREPARE information corresponding to transaction request TX in view v, and then analyze correct nodes S respectively j Representation in view v and view v'. Gtoreq.v:
(A) When the node S is correct j At view v, because of the correct node S j Has received the current master node S p The PRE-PREPARE information corresponding to the transaction request TX transmitted as sn, so S j Does not accept the current master node S p The transmitted PRE-PREPARE information corresponding to transaction request TX' having the same sn but different from TX. Thus, under the same view, the correct node S j The transaction request TX' other than TX is not performed with the number sn.
(B) Correct node S j Requiring a new master node S before switching to the next view p’ Receiving at least (2f+1) VIEW-CHANGE information, which contains at least (f+1) message logs of correct nodes, at a new master node S p’ When constructing a new message log, it is possible to construct the message log corresponding to the cases (a) (b) (c) in the step of constructing the message log in the above step (a 3), and correct node S if the case (a) occurs j TX will be performed at number sn before switching to the next view; if the situation (b) (c) occurs, since at most 2f nodes vote for TX 'with the same number sn in view v'. Gtoreq.v, that is, the PREPARED information corresponding to TX 'is not formed, and the COMMITTED information corresponding to TX' is not generated, the correct node S is in the new view j The transaction request TX' that is different from TX is not performed with the number sn, but rather the voting and the execution of TX is continued according to the NEW-VIEW information.
If S i Receiving the information broadcast in step (4) at view vAt least (2f+1) nodes receive consistent PRE-PREPARE and PRPRETRAD information in view v, including at least (f+1) correct nodes, and the correct nodes S are analyzed separately j Representation in view v and view v'. Gtoreq.v:
(A) When the node S is correct j In view v, since the current master node S has been accepted by at least (f+1) correct nodes p The PRE-PREPARE information corresponding to the transmitted transaction request TX numbered sn and not receiving the current master node S p The transmitted PRE-PREPARE information corresponding to transaction request TX 'having the same sn but different from TX, so that at most 2f nodes vote for transaction request TX' numbered sn, so that PREPARED information corresponding to TX 'is not formed, and COMMITTED information corresponding to TX' is not formed, namely under the same view, correct node S j The transaction request TX' other than TX is not performed with the number sn.
(B) Correct node S j Before switching to the next view, a new master node S is present because at least one correct node records the PREPARED information into the message log p’ When constructing a new message log, it is possible to correspond to the cases (a) (b) (d) in the step of constructing a message log in the above step (a 3), if the case (a) occurs, S j TX will be performed at number sn before switching to the next view; if case (b) (d) occurs, since at most 2f nodes vote for TX 'with the same number sn but different from TX in view v'. Gtoreq.v, the PREPARED information corresponding to TX 'is not formed, and the com information corresponding to TX' is not formed. Thus correct node S in the new view j The transaction request TX' that is different from TX is not performed with the number sn, but rather the voting and the execution of TX is continued according to the NEW-VIEW information.
Usability certificate (Liveness)
Proving availability, i.e. proving: if client C initiates a transaction request TX in the blockchain system, the client eventually receives at least (f+1) consistent execution results for TX.
We agree onOnce the client receives the (f+1) consistent execution results, the transaction request is deemed complete. If in view v, the master node S p Is the correct node and the network condition is not an asynchronous network, the current view is said to be stable. Availability is analyzed and demonstrated from the state the view is in:
when the view is in steady state, the correct master node S p After broadcasting the PRE-PREPARE information, after waiting for a long enough time, a corresponding COMMITTED message is generated, and finally all correct nodes execute the transaction request corresponding to the comitted message and feed back to the client C.
When the VIEW is in an unstable state, a long-time incomplete transaction request initiated by the client causes the VIEW to switch, and we assume that (2f+1) nodes broadcast VIEW-CHANGE information, and the new master node S follows p’ Analyzing and proving availability for the correct node:
(A) Novel master node S p’ Is the correct node and all correct nodes receive the correct NEW-VIEW information and all correct nodes will successfully switch to the NEW stable VIEW.
(B) Novel master node S p’ Is the wrong node and all the right nodes do not receive the right NEW-VIEW information, a NEW VIEW switch is caused.
(C) Novel master node S p’ Is an error node, and only a part of correct nodes receive correct NEW-VIEW information, in which case if the error node follows a rule of a consensus method, the part of correct nodes receiving the correct NEW-VIEW information can enter an unstable VIEW; if the error node does not follow the rule of the consensus method, the correct node finally initiates a new view switching request, i.e. whether the error node follows the rule of the consensus method or not, the new view switching is caused.
In case (B) (C), a new view change request is initiated, again bringing the system into one of the states of (a) (B) (C). Since there are at most f erroneous nodes, at most (f+1) view switches are made, and the correct node is selected as the new master node, switching to a stable view. Thus, the system will eventually reach situation (a), i.e. enter a stable view, thereby ensuring usability.

Claims (4)

1. An optimistic Bayesian-preemptive fault-tolerant consensus method without rollback, comprising the steps of:
(1) Client C initiates a transaction in the blockchain system and sends a request m=<REQUEST,TX,σ c >,σ c ←Sign(<REQUEST,TX>) For master node S p Simultaneously, the client C sets a timer, wherein sigma represents a signature, a subscript represents a signer, sign () is a signature function, and TX is a transaction requested to be executed by the client;
master node S p Receiving request M and validating sigma c After signing, broadcast<PRE-PREPARE,M,sn,v,σ p >,σ p ←Sign(<H(M),sn,v>) To all nodes S i I=1, …, (3f+1); the node only processes the information of which the view number is consistent with the view number where the node is located, and the master node S p Setting a timer and waiting for voting information sent by nodes, wherein (3f+1) is the number of nodes in the block chain system and comprises at most f Bayesian nodes and at least 2f+1 correct nodes; v is node S p The view number of the view where sn is the number allocated to the request M by the master node;
(2) Node S i Receiving the signal from step (1)<PRE-PREPARE,M,sn,v,σ p >Verify sigma p Then vote and send it<PREPARE,H(M),sn,v,σ i >,σ i ←Sign(<H(M),sn,v>) For master node S p ；
(3) Master node S p Judging whether the voting information is optimistic according to the quantity of the received voting information and broadcasting information to other nodes, wherein if the master node S p If the number of the received consistent voting information is 3f+1, the situation is optimistic, and if the master node S p The number of the received consistent voting information is 2f+1-3 f, and the situation is general;
(4) If the step (3) is determined to be the general case node S i According to the master node S p Second round of broadcasting of broadcast informationTicket, node S, if optimistic i According to the master node S p The broadcasted information directly executes the request and feeds back the result to the client C; master node S after the second round of voting p Judging whether the request can be executed or not according to the voting result, if so, broadcasting information to other nodes, and the other nodes according to the master node S p The broadcasted information directly executes the request and feeds back the result to the client C;
in the execution process of the steps (1) - (4), if the node finds that the master node has the Bayesian behavior, the node broadcasts the view change request information to elect a new master node, and the subsequent consensus is completed under the new master node.
2. The optimistic, back-off free, bayer fault-tolerant consensus method according to claim 1, wherein step (3) is implemented by the sub-steps of:
(3.1) judging the system state: master node S p Before the timer expires, the system state is considered to be optimistic once consistent voting information from 3f+1 different node signatures is received; if the master node S p Only consistent voting information of 2f+1 to 3f different node signatures is received at the end of the timer<PREPARE,H(M),sn,v,σ i >The system state is considered to be a general case; wherein the consistent voting information is H (M), sn, v are the same and the signature is correct<PREPARE,H(M),sn,v,σ i >；
(3.2) Master node S p Tells other nodes according to the system state broadcast information: under optimistic conditions, the master node S p Aggregating the received 2f+1 different node signaturesAggre () is a signature aggregation function and broadcasts informationTo all nodes S i The method comprises the steps of carrying out a first treatment on the surface of the In general, a master node S p Aggregating 2f+1 signatures in the received 2f+1 to 3f different node signatures +.>And broadcast information +.> To all nodes S i 。
3. The optimistic, back-off free, bayer fault-tolerant consensus method according to claim 2, wherein step (4) is specifically:
if node S i Receiving the master node S in step (3.2) p Transmitted informationDirectly executing the corresponding request after verifying the signature, and transmitting<REPLY,res,sn,v,σ i ”>,σ i ”←Sign(<H (res), sn, v) to the client C, wherein res is the result of executing the request;
if node S i Receiving the master node S in step (3.2) p Transmitted informationAfter verifying the signature, carrying out a second round of voting on the corresponding request, and sending<COMMIT,H(M),sn,v,σ i ’>,σ i ’←Sign(<H(M),sn,v,COMMIT>) For master node S p ；
Master node S p Once consistent voting information of the transmitted 2f+1 different node signatures is received<COMMIT,H(M),sn,v,σ i ’>The request is considered to be executable by the master node S p Aggregating 2f+1 different node signaturesAnd broadcast information +.>To all nodes S i ；
If node S i Receiving the master node S p Transmitted byDirectly execute the request after verifying both aggregate signatures and send +.>To client C.
4. A method of optimistic, back-off free, bayer fault-tolerant consensus according to claim 3, wherein if a node finds that a master node has a bayer behaviour, broadcasting view change request information to elect a new master node is achieved by the sub-steps of:
(a1) Detecting the Bayesian behavior: if client C does not receive consistent result information of at least f+1 different node signatures within a prescribed time, broadcast information m=<REQUEST,TX,σ c >To all nodes S i When node S i Starting a timer after receiving the information, if the timer is finished before S i Without receipt of the master node S p Any information sent corresponding to the request M or in the verification S p Detecting Bayesian behavior in signing of transmitted information S i Broadcasting view change request information<REQ-VIEW-CHANGE,v,σ rv i >,σ rv i ζ (REQ-VIEW-CHANGE, v) to request election of a new master node;
(a2) Node S i Upon receipt of consistent view change request information signed by f+1 different nodes<REQ-VIEW-CHANGE,v,σ rv i >Broadcast a message carrying a local message log L<VIEW-CHANGE,v+1,L,σ L i >,σ L i ←Sign(<H(L)>) Indicating that a new master node is ready to be elected; wherein L contains all P received by the nodeRE-PREPARE, PREPARED, COMMITTED information;
(a3) Constructing a new message log: node S i Upon receipt of a coincidence of 2f+1 different node signatures<VIEW-CHANGE,v+1,L,σ L i >The node constructs a new message log based on the received 2f+1 message logs and the following rules
a. If the COMMITTED information broadcasted in the step (4) or the step (3.2) exists in the message log, adding PRE-PREPARE information corresponding to the informationAnd marks it as "to be executed";
b. if f+1 PRE-PREPARE information broadcast in the step (1) with consistent and correct signature exists in the message log, PRE-PREPARE information broadcast in the step (3.2) with the same sn and correct signature exists, but the corresponding PRE-PREPARE information is different from the f+1 consistent PRE-PREPARE information, PRE-PREPARE information corresponding to the information with larger view number is selected to be added toAnd marks it as "to vote";
c. if there are only f+1 identical PRE-PREPARE information broadcast in step (1) with correct signature in the message log, adding the PRE-PREPARE information to the message logAnd marks it as "to vote";
d. if there is only PREPARE information broadcasted in the step (3.2) with correct signature in the message log, adding PRE-PREPARE information corresponding to the information to the message logAnd marks it as "to vote";
the node which is completed by the first construction is used as a new master node S p’ And broadcast To all nodes S i ；
(a4) View replacement: if node S i Receiving the message broadcast in step (a 3)Verify signature and use the structure->Method verification of->After that, the message log is +_ according to the following rules>Processing the information in the process:
a. for PRE-PREPARE information marked as 'to be executed', directly executing the corresponding transaction request and sending<REPLY,res,sn,v+1,σ i ”’>,σ i ”’←Sign(<H (res), sn, v+1) to the client C, where res is the result of executing the request;
b. for PRE-PREPARE information marked as 'to-be-voted', changing to a new view v+1, voting for the corresponding request for the second round, and sending<COMMIT,H(M),sn,v+1,σ i ’>,σ i ’←Sign(<H(M),sn,v+1,COMMIT>) For master node S p’ The master node continues to judge whether the request can be executed or not according to the second round of voting, if the request can be broadcasted, other nodes are informed of the information, and the other nodes are according to the master node S p Broadcast information directExecuting the request and feeding back the result to the client C.
CN202111452583.8A 2021-12-01 2021-12-01 Optimistic Bayesian-preemption fault-tolerant consensus method without rollback Active CN114205092B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111452583.8A CN114205092B (en) 2021-12-01 2021-12-01 Optimistic Bayesian-preemption fault-tolerant consensus method without rollback

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111452583.8A CN114205092B (en) 2021-12-01 2021-12-01 Optimistic Bayesian-preemption fault-tolerant consensus method without rollback

Publications (2)

Publication Number Publication Date
CN114205092A CN114205092A (en) 2022-03-18
CN114205092B true CN114205092B (en) 2023-11-21

Family

ID=80649922

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111452583.8A Active CN114205092B (en) 2021-12-01 2021-12-01 Optimistic Bayesian-preemption fault-tolerant consensus method without rollback

Country Status (1)

Country Link
CN (1) CN114205092B (en)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109347804A (en) * 2018-09-19 2019-02-15 电子科技大学 A kind of Byzantine failure tolerance common recognition optimization method for block chain
CN109447795A (en) * 2018-09-11 2019-03-08 中国人民解放军国防科技大学 Byzantine consensus method supporting rapid achievement of final confirmation
KR20210061243A (en) * 2019-11-19 2021-05-27 한양대학교 산학협력단 Blockchain consensus method based on variable quorum, blockcahin node device and program using the same
CN113645044A (en) * 2021-10-09 2021-11-12 支付宝(杭州)信息技术有限公司 Consensus method, block chain system and consensus node

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11334561B2 (en) * 2019-07-24 2022-05-17 Vmware, Inc. Flexible byzantine fault tolerant protocol using message delay upper bound for client commit decision

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109447795A (en) * 2018-09-11 2019-03-08 中国人民解放军国防科技大学 Byzantine consensus method supporting rapid achievement of final confirmation
CN109347804A (en) * 2018-09-19 2019-02-15 电子科技大学 A kind of Byzantine failure tolerance common recognition optimization method for block chain
KR20210061243A (en) * 2019-11-19 2021-05-27 한양대학교 산학협력단 Blockchain consensus method based on variable quorum, blockcahin node device and program using the same
CN113645044A (en) * 2021-10-09 2021-11-12 支付宝(杭州)信息技术有限公司 Consensus method, block chain system and consensus node

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
可应用于联盟链的拜占庭容错共识算法;王日宏;张立锋;徐泉清;周航;计算机应用研究(第011期);全文 *
蔡亮 ; 李伟 ; 王灿 ; 邱炜伟 ; 杨小虎 ; 徐仁艳 ; 李启雷 ; 尹可挺 ; 匡立中 ; 张帅 ; 宋士正 ; 杨国正 ; 陈晓丰.高效自主可控区块链基础平台关键技术及应用.2020年度浙江省登记成果汇编.2020,全文. *

Also Published As

Publication number Publication date
CN114205092A (en) 2022-03-18

Similar Documents

Publication Publication Date Title
CN110677485B (en) Dynamic layered Byzantine fault-tolerant consensus method based on credit
CN111355810B (en) Improved PBFT consensus method based on credit and voting mechanism
CN110784346B (en) Reputation value-based PBFT consensus system and method
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
CN110943838A (en) Method, apparatus and storage medium for determining consensus of blocks in a blockchain network
CN114048517B (en) Dual channel consensus system and method for blockchains, computer readable storage medium
CN112532396A (en) Optimized Byzantine fault-tolerant method based on aggregated signature and storage medium
CN112636905B (en) System and method for extensible consensus mechanism based on multiple roles
CN112417046B (en) Parallelization Bayesian-busy fault-tolerant method applied to block chain consensus mechanism
He et al. An improvement of consensus fault tolerant algorithm applied to alliance chain
CN111342971A (en) Byzantine consensus method and system
CN112788137A (en) Alliance chain consensus method based on RAFT algorithm
CN111682942A (en) Binary weighted Byzantine fault-tolerant consensus method applied to permit chain
CN114050904A (en) Consensus system and method based on two-level leader node fragmentation structure
CN114422513A (en) Block chain consensus method based on Raft-PBFT
CN112395113A (en) Practical Byzantine fault-tolerant consensus method and device and readable storage medium
CN116582543A (en) Consensus method based on slice
CN111555858A (en) Practical Byzantine fault-tolerant consensus method based on block chain type storage
CN114205092B (en) Optimistic Bayesian-preemption fault-tolerant consensus method without rollback
CN114140233A (en) Safe cross-slice view conversion method and device for partitioned block chain
CN111064813B (en) Method and device for synchronizing processing messages during block chain consensus processing
CN115378788B (en) Block chain performance self-adaptive optimization method based on hierarchical consensus and reinforcement learning
CN114499874B (en) Bayesian-busy-family fault-tolerant consensus optimization method applied to industrial Internet
CN113992398A (en) Improved PBFT consensus algorithm

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
GR01 Patent grant
GR01 Patent grant