CN114205092A - Optimistic byzantine fault-tolerant consensus method without backspacing - Google Patents

Optimistic byzantine fault-tolerant consensus method without backspacing Download PDF

Info

Publication number
CN114205092A
CN114205092A CN202111452583.8A CN202111452583A CN114205092A CN 114205092 A CN114205092 A CN 114205092A CN 202111452583 A CN202111452583 A CN 202111452583A CN 114205092 A CN114205092 A CN 114205092A
Authority
CN
China
Prior art keywords
information
node
request
master node
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.)
Granted
Application number
CN202111452583.8A
Other languages
Chinese (zh)
Other versions
CN114205092B (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

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/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

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Finance (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computing Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Signal Processing (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Technology Law (AREA)
  • General Business, Economics & Management (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Hardware Redundancy (AREA)

Abstract

The invention discloses an optimistic Byzantine fault-tolerant consensus method without backspacing, which comprises the steps that a main node initiates a proposal, all nodes carry out first-round voting on the proposal, the main node judges whether the condition of a system is an optimistic condition or not according to the voting result of the first round, and different consensus methods are adopted to carry out consensus on the proposal under the optimistic condition and the non-optimistic condition; all nodes verify the proposal request sent by the main node and execute corresponding operation according to the message type; in this process, if a node finds that a master node has byzantine behavior, a view change request is broadcast to elect a new master node. The invention can be applied to the consensus layer as the consensus protocol in the block chain application, has simple implementation method and strong universality, effectively reduces the consumption of bandwidth, and has the advantages of high efficiency, high robustness and the like.

Description

Optimistic byzantine fault-tolerant consensus method without backspacing
Technical Field
The invention relates to the technical field of block chains, in particular to an optimistic Byzantine Fault Tolerance (BFT) consensus method without backspacing.
Background
The practical Byzantine fault-tolerant consensus algorithm is proposed in 1999 by Miguel-Carlsterol (Miguel Castro) and Barbara-Rickov (Barbara Liskov), the problem that the original Byzantine fault-tolerant algorithm is low in efficiency is solved, the method enables all nodes to achieve consensus through two rounds of voting, and due to the fact that voting behaviors of the nodes need to broadcast information and the communication complexity is too high, the performance of a general system is sharply reduced when the number of the nodes reaches about 100.
The aggregated signature technology can combine a plurality of signatures into one signature, only one verification operation needs to be carried out on the aggregated signature, the signatures of a plurality of received voting information can be aggregated by using the technology, and the aggregated signature can be used as a certificate of signatures of a plurality of nodes. By utilizing the characteristic, the communication complexity can be reduced to a certain degree, but two rounds of voting are still required to be carried out when the nodes are required to achieve consensus.
A speculative byzantine fault-tolerant consensus algorithm was proposed in 2007 by romo krischna Kotla, which uses an aggregate signature technique to effectively reduce communication complexity and optimizes the algorithm for a byzantine-free 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 on the state of the system is required.
The existing Byzantine fault-tolerant algorithm needs two rounds of voting, or reduces the number of voting rounds by adopting a speculative execution method, and introduces the problem of needing state rollback operation, so that the problem of how to improve the efficiency of the consensus process still remains to be solved.
Disclosure of Invention
The invention aims to provide an optimistic Byzantine fault-tolerant consensus method without rollback aiming at the defects of the prior art.
The purpose of the invention is realized by the following technical scheme: an optimistic fallback-free Byzantine fault-tolerant consensus method comprises the following steps:
(1) client C initiates a transaction and sends a request M in the blockchain system<REQUEST,TX,σc>,σc←Sign(<REQUEST,TX>) For the master node SpMeanwhile, the client C sets a timer, wherein σ represents a signature, subscript represents a signer, Sign () is a signature function, and TX is a transaction requested to be executed by the client;
master node SpReceiving request M and verifying sigmacAfter signing, broadcasting<PRE-PREPARE,M,sn,v,σp>,σp←Sign(<H(M),sn,v>) To all nodes SiI ═ 1, …, (3f + 1); the node only processes the information with the view number consistent with the view number of the node, and the master node SpAnd setting a timer and waiting for voting information sent by the node. Wherein, (3f +1) is the number of nodes in the blockchain system, and comprises at most f Byzantine nodes and at least (2f +1) correct nodes; v is node SpView number of the view, sn is the number assigned to the request M by the master node;
(2) node SiReceived from step (1)<PRE-PREPARE,M,sn,v,σp>Verification of σpThen voting and sending the same<PREPARE,H(M),sn,v,σi>,σi←Sign(<H(M),sn,v>) For the master node Sp；
(3) Master node SpJudging whether the voting information is optimistic or not according to the number of the received voting information and broadcasting the information to tell other nodes, wherein if the main node SpIf the number of the received consistent voting information is (3f +1), the situation is optimistic, and if the master node SpThe number of the received consistent voting information is (2f +1) -3 f, which is a general case;
(4) if the step (3) judges that the node S is a common node SiAccording to the master node SpThe broadcasted information is voted for the second round, if the situation is optimistic, the node SiAccording to the master node SpDirect execution of broadcasted informationRequesting and feeding back a result to the client C; second round post-vote master node SpJudging whether the request can be executed according to the voting result, if the request can be informed to other nodes by broadcasting information, other nodes can execute the request according to the main node SpThe 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 a Byzantine behavior, the node broadcasts view change request information to elect a new master node, and the subsequent consensus is completed under the new master node.
Further, the step (3) is realized by the following sub-steps:
(3.1) judging the system state: master node SpBefore the timer is finished, once consistent voting information from (3f +1) different node signatures is received, the system state is considered to be an optimistic situation; if the master node SpOnly receiving the consistent voting information of (2f +1) -3 f different node signatures when the timer is ended<PREPARE,H(M),sn,v,σi>If so, the system state is considered as a general condition; the consistent voting information is H (M), sn and v are the same and the signature is correct<PREPARE,H(M),sn,v,σi>。
(3.2) Master node SpAnd telling other nodes according to the system state broadcast information: under optimistic conditions, the master node SpAggregating received (3f +1) different node signatures
Figure BDA0003386740740000021
Aggre () is a signature aggregation function and broadcasts information
Figure BDA0003386740740000022
To all nodes Si(ii) a Typically, the master node SpAggregating (2f +1) signatures in the received (2f +1) -3 f different node signatures
Figure BDA0003386740740000027
And broadcasting the information
Figure BDA0003386740740000023
Figure BDA0003386740740000024
To all nodes Si。
Further, the step (4) is specifically as follows:
if node SiReceiving the master node S in the step (3.2)pTransmitted information
Figure BDA0003386740740000025
After the signature is verified, the corresponding request is directly executed and sent<REPLY,res,sn,v,σi”>,σi”←Sign(<H (res), sn, v) to the client C, where res is the result of executing the request;
if node SiReceiving the master node S in the step (3.2)pTransmitted information
Figure BDA0003386740740000026
After the signature is verified, the corresponding request is subjected to a second round of voting, and is sent<COMMIT,H(M),sn,v,σi’>,σi’←Sign(<H(M),sn,v,COMMIT>) For the master node Sp；
Master node SpOnce the consistent voting information signed by (2f +1) different nodes is received<COMMIT,H(M),sn,v,σi’>The request is considered to be executable, master node SpAggregating (2f +1) different node signatures
Figure BDA0003386740740000031
And broadcasting the information
Figure BDA0003386740740000032
To all nodes Si；
If node SiReceiving a master node SpTransmitted by
Figure BDA0003386740740000033
Directly executing the request after verifying the two aggregated signatures, and sending<REPLY,res,sn,v,σi”>，σi”←Sign(<H(res),sn,v>) To the client C.
Further, if the node finds that the master node has a byzantine behavior, broadcasting the view change request information to elect a new master node is implemented by the following sub-steps:
(a1) detecting byzantine behaviour: if the client C does not receive the consistent result information of at least (f +1) different node signatures within the specified time, the broadcast information M is equal to<REQUEST,TX,σc>To all nodes SiWhen node SiStarting a timer after receiving the information, and starting S before the timer is endediHas not received the master node SpAny information sent corresponding to the request M or during the authentication SpByzantine behaviour is discovered upon signing of transmitted information, SiBroadcast view change request information<REQ-VIEW-CHANGE,v,σrv i>,σrv iEither ← Sign (REQ-VIEW-CHANGE, v) to request election of a new master node;
(a2) node SiUpon receipt of consistent view change request information signed by (f +1) different nodes<REQ-VIEW-CHANGE,v,σrv i>Then broadcast a message carrying local message log L<VIEW-CHANGE,v+1,L,σL i>,σL i←Sign(<H(L)>) Indicating that a new master node is ready for election; wherein, L contains all the information of PRE-PREPARE, PREPARED and COMMITTED received by the node;
(a3) constructing a new message log: node SiUpon receipt of consistent (2f +1) different node signatures<VIEW-CHANGE,v+1,L,σL i>Then the node constructs a new message log according to the received (2f +1) message logs and the following rules
Figure BDA0003386740740000034
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 information into the message log
Figure BDA0003386740740000035
And mark it as "to be executed";
b. if there are (f +1) pieces of M, sn, v in the message log and the PRE-PREPARE information broadcast in step (1) with consistent signature and correct signature, and there is the PREPARED information broadcast in step (3.2) with the same sn and correct signature but the corresponding PRE-PREPARE information is different from the (f +1) pieces of consistent PRE-PREPARE information, then the PRE-PREPARE information corresponding to the information with larger view number is selected and added to the message log
Figure BDA0003386740740000036
And mark it as "to vote";
c. if only (f +1) consistent PRE-PREPARE information with correct signature broadcast in the step (1) exists in the message log, adding the PRE-PREPARE information to the message log
Figure BDA0003386740740000037
And mark it as "to vote";
d. if only the PREPARED information broadcasted in the step (3.2) with correct signature exists in the message log, the PRE-PREPARE information corresponding to the information is added to the message log
Figure BDA0003386740740000038
And mark it as "to vote";
the node which is constructed first is used as a new main node Sp’And broadcast
Figure BDA0003386740740000039
Figure BDA0003386740740000041
To all nodes Si；
(a4) View replacement: if node SiReceiving the message broadcast by the step (a3)
Figure BDA0003386740740000042
Verifying signatures and constructs
Figure BDA0003386740740000043
Method of (1) verifying
Figure BDA0003386740740000044
Thereafter, the message is logged according to the following rules
Figure BDA0003386740740000045
The information in (2) is processed:
a. aiming at the PRE-PREPARE information marked as 'to be executed', directly executing the corresponding transaction request and sending the transaction request<REPLY,res,sn,v+1,σi”’>,σi”’←Sign(<H (res), sn, v +1) to the client C, where res is a result of executing the request;
b. for the PRE-PREPARE information marked as 'to be voted', the view is changed to a new view v +1, and the corresponding request is voted for the second time, and the information is sent<COMMIT,H(M),sn,v+1,σi’>,σi’←Sign(<H(M),sn,v+1,COMMIT>) For the master node Sp’The main node continues to judge whether the request can be executed according to the second round of voting, if the request can be informed to other nodes by broadcasting information, the other nodes inform the other nodes according to the main node SpThe broadcasted information directly executes the request and feeds back the result to the client C.
The invention has the advantages that when the system does not have the Byzantine behavior, namely under the optimistic condition, the nodes can achieve consensus only by one round of voting, the confirmation delay is effectively reduced, the information amount in the system is greatly reduced, and the throughput is obviously improved. And in general conditions, the state rollback is not needed, 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 guaranteed.
Drawings
Fig. 1 is a communication mode of the invention in an optimistic situation.
Fig. 2 is a communication mode of the present invention in a general case.
Detailed Description
The present invention is described in detail below with reference to the accompanying drawings.
The invention discloses an optimistic Byzantine fault-tolerant consensus method without backspacing, which comprises the following steps:
(1) the master node broadcasts the proposal.
Assuming that there are (3f +1) nodes in the system, including at most f Byzantine nodes and at least (2f +1) correct nodes, the message is signed using the BLS (Boneh-Lynn-Shacham) signature algorithm to achieve aggregated signature. Client C sends request M ═<REQUEST,TX,σc>(where σc←Sign(<REQUEST,TX>) Is the client' S signature information, Sign () is the signature function, TX is the transaction the client requests to perform) to the master node SpMeanwhile, the client C sets a timer (the size of the timer can be set to an appropriate value according to the network condition), and the master node SpReceive M and verify σcThen, broadcast<PRE-PREPARE,M,sn,v,σp>To all nodes Si(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 SpSignature information of, while the master node SpSetting a timer (the timer can be set to an appropriate value according to network conditions) and waiting for the voting information sent by the node (where v is the node S)pView number of the located view, sn is the number allocated to the request M by the master node, H () is a hash function, all nodes judge the view number of each received message, and the nodes only process 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 SiReceived from step (1)<PRE-PREPARE,M,sn,v,σp>Verification of σpThen voting and sending the same<PREPARE,H(M),sn,v,σi>For the master node Sp(where σi←Sign(<H(M),sn,v>) Is node SiSignature information of).
(3) Master node SpAnd judging whether the received voting information quantity is an optimistic situation or not and broadcasting information to tell other nodes.
This step is the core of the present invention and is divided into the following substeps.
And (3.1) judging the system state.
After the first round of voting, the master node receives the voting information (including its own) sent by the node within a specified time. Master node SpBefore the timer is over, the consistent voting information from (3f +1) different node signatures is received once<PREPARE,H(M),sn,v,σi>(the corresponding h (m) is required, sn, v are the same, and the signature is correct), the system status is considered to be optimistic. If the master node SpWhen the timer is over, the consistent voting information from (3f +1) different node signatures but from (2f +1) -3 f different node signatures is not received<PREPARE,H(M),sn,v,σi>(the corresponding H (M) is required, sn and v are the same, and the signature is correct), the system status is considered as a general case. If the master node SpReceiving consistent voting information with less than (2f +1) different node signatures at the end of the timer<PREPARE,H(M),sn,v,σi>And no processing is performed.
And (3.2) the main node executes corresponding operation according to the system state.
Under optimistic conditions, the master node SpAggregating signatures
Figure BDA0003386740740000051
({σiIs a set of (3f +1) signatures, Aggre () is a signature aggregation function), and broadcasts information
Figure BDA0003386740740000052
To all nodes Si. Typically, the master node SpAggregating signatures
Figure BDA0003386740740000053
({σiIs a set of (2f +1) signatures from (2f +1) -3 f signatures, and Aggre () is a signature aggregation function), and broadcasts information
Figure BDA0003386740740000054
Figure BDA0003386740740000055
To all nodes Si。
(4) And (4) judging to carry out voting or request execution of the second round by the node according to the information sent in the step (3).
The step is the core of the invention, and specifically comprises the following steps:
if node SiReceiving the master node S in the step (3.2)pTransmitted information
Figure BDA0003386740740000056
Then directly executes its corresponding request after verifying the signature and sends it<REPLY,res,sn,v,σi”>To client C (where σi”←Sign(<H (res), sn, v), res being the result of executing the request), as shown in fig. 1.
If node SiReceiving the master node S in the step (3.2)pTransmitted information
Figure BDA0003386740740000057
After the signature is verified, a second round of voting is performed on its corresponding request, as shown in fig. 2, and the transmission is sent<COMMIT,H(M),sn,v,σi’>(where σi’←Sign(<H(M),sn,v,COMMIT>) To the master node S)p. The master node determines whether the request can be executed after the second round of voting:
master node SpOnce the consistent second round voting information of (2f +1) different node signatures is received<COMMIT,H(M),sn,v,σi’>The request is considered to be executable, master node SpAggregating signatures
Figure BDA0003386740740000058
({σi' } is a set of (2f +1) signatures), and broadcasts information
Figure BDA0003386740740000061
To all nodes Si(
Figure BDA0003386740740000062
For the corresponding aggregation in the PREPARED information in step (3.2)A composite signature).
If node SiReceiving a master node SpTransmitted by
Figure BDA0003386740740000063
Directly executing the request after verifying the signature and sending<REPLY,res,sn,v,σi”>To client C (where σi”←Sign(<H (res), sn, v), res being the result of executing the request).
In the whole process, if the node finds that the main node has the Byzantine behavior, the view change request information is broadcasted to elect a new main node.
This step is the core of the present invention and is divided into the following substeps.
(a1) Detecting byzantine behaviour.
If the client C does not receive the consistent information of at least (f +1) different node signatures within the specified time<REPLY,res,sn,v,σi”>If the broadcast information M is equal to<REQUEST,TX,σc>To all nodes SiWhen node SiStarting a timer after receiving the information, and if the timer is over, SiHas not received the master node SpAny information sent corresponding to the request is considered to be the current master node SpPresence of Byzantine behaviour, SiBroadcast view change request information<REQ-VIEW-CHANGE,v,σi>To request election of a new master node. If it is verified SpThe transmitted information is signed, if Byzantine behavior is found, i.e. verification is not passed, and the information is transmitted in the same way<REQ-VIEW-CHANGE,v,σrv i>(where v is node SiCurrent view number of σrv i←Sign(<REQ-VIEW-CHANGE,v>))。
(a2) Node SiUpon receipt of consistent view change request information signed by (f +1) different nodes<REQ-VIEW-CHANGE,v,σrv i>Then broadcast a message carrying 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 nodeL i←Sign(<H(L)>))。
(a3) A message log is constructed.
Node SiUpon receipt of consistent (2f +1) different node signatures<VIEW-CHANGE,v+1,L,σL i>Then the node constructs a new message log according to the received (2f +1) message logs and the following rules
Figure BDA0003386740740000064
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 information into the message log
Figure BDA0003386740740000065
And mark it as "to be executed".
b. If there are (f +1) identical PRE-PREPARE information (corresponding M, sn, v are all the same) broadcast in the step (1) with correct signature in the message log, and there is PREPARED information broadcast in the step (3.2) with the same sn and correct signature, but the corresponding PRE-PREPARE information is different from the (f +1) identical PRE-PREPARE information, then selecting the PRE-PREPARE information corresponding to the information with larger view number to be added to the message log
Figure BDA0003386740740000066
And marks it as "to vote".
c. If only (f +1) consistent PRE-PREPARE information with correct signature broadcast in the step (1) exists in the message log, adding the PRE-PREPARE information to the message log
Figure BDA0003386740740000071
And marks it as "to vote".
d. If only the PREPARED information broadcasted in the step (3.2) with correct signature exists in the message log, the PRE-PREPARE information corresponding to the information is added to the message log
Figure BDA0003386740740000072
And marks it as "to vote".
The node which is constructed first is used as a new main node Sp’And broadcast
Figure BDA0003386740740000073
To all nodes Si(wherein
Figure BDA0003386740740000074
(a4) And (6) view replacement.
If node SiReceiving the message broadcast by the step (a3)
Figure BDA0003386740740000075
Verifying signatures and constructs
Figure BDA0003386740740000076
Method of (1) verifying
Figure BDA0003386740740000077
Thereafter, the message is logged according to the following rules
Figure BDA0003386740740000078
The information in (2) is processed:
a. aiming at the PRE-PREPARE information marked as 'to be executed', directly executing the corresponding transaction request and sending the transaction request<REPLY,res,sn,v+1,σi”’>To client C, where σi”’←Sign(<H(res),sn,v+1>) Res is the result of executing the request).
b. For the PRE-PREPARE information marked as 'to be voted', the view is changed to a new view v +1, and the corresponding request is voted for the second time, and the information is sent<COMMIT,H(M),sn,v+1,σi’>For the master node Sp’(where σi’←Sign(<H(M),sn,v+1,COMMIT>) Then the main node judges whether the request can be executed after the second round of voting, if so, the broadcast information tells other nodes, and the other nodes tell the request according to the main node SpThe broadcasted information directly executes the request and feeds back the result to the clientC。
Safety certification (Safety)
The method is to be proven safe, i.e. to prove that: if the correct node SiIf the transaction request TX is executed with the number sn in the view v, there will not be the correct node SjTransaction requests TX 'other than TX are executed with number sn in view v' ≧ v.
Assuming the correct node SiThe transaction request TX is executed with number sn in view v, SiIt may receive the COMMITTED information broadcast in step (4) or step (3.2) of the embodiment:
if SiBroadcast in step (3.2) received in view v
Figure BDA0003386740740000079
Then (3f +1) nodes receive the PRE-PREPARE information corresponding to the transaction request TX in view v, and the correct node S is analyzed belowjThe expression in view v and view v' ≧ v:
(A) when the correct node SjIn view v, because of the correct node SjHas received the current master node SpThe transmitted transaction request TX with number sn corresponds to PRE-PREPARE information, so SjWill not accept the current master node SpAnd the transmitted transaction request TX' with the same sn but different from TX corresponds to PRE-PREPARE information. Thus, under the same view, the correct node SjTransaction requests TX' other than TX are not executed with the number sn.
(B) Correct node SjRequiring a new master node S before switching to the next viewp’Receiving at least (2f +1) VIEW-CHANGE messages containing message logs of at least (f +1) correct nodes, at the new master node Sp’When constructing a new message log, it is possible to correspond to the case (a) (b) (c) in the step of constructing a message log in the above-mentioned step (a3), and if the case (a) occurs, the correct node SjTX will be performed with number sn before switching to the next view; if the case (b) (c) occurs, since there are at most 2f node pairs voting for TX ' with the same number sn in the view v ' ≧ v, that is, no PREPA corresponding to TX ' is formedRED information, rather than COMMITTED information corresponding to TX', so that the correct node S is in the new viewjTransaction requests TX' other than TX will not be executed with number sn, but will continue to vote and execute for TX based on NEW-VIEW information.
If SiReceiving the information broadcast in step (4) in view v
Figure BDA0003386740740000081
At least (2f +1) nodes receive the consistent PRE-PREPARE and PREPRAED information in view v, which contains at least (f +1) correct nodes, and the correct nodes S are analyzed separately belowjThe expression in view v and view v' ≧ v:
(A) when the correct node SjIn view v, since at least (f +1) correct nodes have accepted the current master node SpThe transmitted transaction request TX with the number sn corresponds to PRE-PREPARE information and does not accept the current master node SpThe sent PRE-PREPARE information corresponding to the transaction request TX 'with the same sn but different from TX is provided, so that at most 2f nodes vote for the transaction request TX' with the sn number, therefore, the PREPARED information corresponding to TX 'cannot be formed, and the COMMITTED information corresponding to TX' cannot be formed, namely, under the same view, the correct node SjTransaction requests TX' other than TX are not executed with the number sn.
(B) Correct node SjThe new master node S is arranged to record the PREPARED information in the message log for at least one correct node before switching to the next viewp’Constructing a new message log may correspond to the case (a) (b) (d) of the message log constructing step of step (a3) above, and if the case (a) occurs, SjTX will be performed with number sn before switching to the next view; if the condition (b) (d) occurs, since at most 2f node pairs vote for TX 'with the same number as sn but different from TX in the view v' ≧ v, no PREPARED information corresponding to TX 'and no COMMITTED information corresponding to TX' are formed. So the correct node S is in the new viewjTransaction requests TX' different from TX are not executed with number sn, butThe TX may continue to be voted and executed based on the NEW-VIEW information.
Proof of availability (Liveness)
Demonstration of availability, i.e. demonstration of: if client C initiates a transaction request TX in the blockchain system, the client will eventually receive at least (f +1) consistent execution results regarding TX.
We agree that once the client receives (f +1) consistent execution results, the transaction request is considered complete. If in view v, the master node SpIs the correct node and the network condition is not asynchronous, the current view is said to be stable. The following analyzes and proves availability from the state the view is in:
when the view is in steady state, the correct master node SpAfter broadcasting the PRE-PREPARE information, after a long enough time of waiting, a corresponding COMMITTED information must be generated, and finally all correct nodes execute the transaction request corresponding to the COMMITTED information and feed back to the client C.
When the VIEW is in an unstable state, the VIEW switching is caused when the transaction request initiated by the client is not completed for a long time, and we assume that (2f +1) nodes broadcast VIEW-CHANGE information, and a new master node S is followedp’Whether to analyze and prove availability for the correct node:
(A) new master node Sp’Is the correct node and all correct nodes receive the correct NEW-VIEW information, all correct nodes will successfully switch to the NEW stable VIEW.
(B) New master node Sp’Is the wrong node and all correct nodes have not received the correct NEW-VIEW information, a NEW VIEW switch is caused.
(C) New master node Sp’The node is a wrong node, and only a part of correct nodes receive correct NEW-VIEW information, in this case, if the wrong node follows the rule of the consensus method, the part of correct nodes receiving correct NEW-VIEW information can enter an unstable VIEW; if the wrong node does not follow the rule of the consensus method, the correct node will eventually initiate a new view switch request, i.e. regardless of whether the rule of the consensus method is followedWhether the wrong node follows the consensus method rule or not causes a new view switch.
In case (B) (C), a new view change request is initiated, again bringing the system into one of the states (a) (B) (C). Since there are at most f error nodes, if (f +1) view switching is performed at most, a correct node is selected as a new master node, so as to switch to a stable view. Thus, the system will eventually reach situation (a), i.e. enter a stable view, thereby guaranteeing usability.

Claims (4)

1. An optimistic fallback-free Byzantine fault-tolerant consensus method is characterized by comprising the following steps of:
(1) client C initiates a transaction and sends a request M in the blockchain system<REQUEST，TX，σc>，σc←Sign(<REQUEST，TX>) For the master node SpMeanwhile, the client C sets a timer, wherein σ represents a signature, subscript represents a signer, Sign () is a signature function, and TX is a transaction requested to be executed by the client;
master node SpReceiving request M and verifying sigmacAfter signing, broadcasting<PRE-PREPARE，M，sn，v，σp>，σp←Sign(<H(M)，sn，v>) To all nodes Si1, (3f + 1); the node only processes the information with the view number consistent with the view number of the node, and the master node SpSetting a timer and waiting for voting information sent by nodes, wherein (3f +1) is the number of nodes in a block chain system, and the number of nodes comprises at most f Byzantine nodes and at least (2f +1) correct nodes; v is node SpView number of the view, sn is the number assigned to the request M by the master node;
(2) node SiReceived from step (1)<PRE-PREPARE，M，sn，v，σp>Verification of σpThen voting and sending the same<PREPARE，H(M)，sn，v，σi>，σi←Sign(<H(M)，sn，v>) For the master node Sp；
(3) Master node SpAccording to the received voting letterJudging whether the information quantity is an optimistic situation or not and broadcasting the information to tell other nodes, wherein if the main node SpIf the number of the received consistent voting information is (3f +1), the situation is optimistic, and if the master node SpThe number of the received consistent voting information is (2f +1) -3 f, which is a general case;
(4) if the step (3) judges that the node S is a common node SiAccording to the master node SpThe broadcasted information is voted for the second round, if the situation is optimistic, the node SiAccording to the master node SpThe broadcasted information directly executes the request and feeds back the result to the client C; second round post-vote master node SpJudging whether the request can be executed according to the voting result, if the request can be informed to other nodes by broadcasting information, other nodes can execute the request according to the main node SpThe 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 a Byzantine behavior, the node broadcasts view change request information to elect a new master node, and the subsequent consensus is completed under the new master node.
2. The optimistic fallback-free byzantine fault-tolerant consensus method according to claim 1, wherein said step (3) is achieved by the following sub-steps:
(3.1) judging the system state: master node SpBefore the timer is finished, once consistent voting information from (3f +1) different node signatures is received, the system state is considered to be an optimistic situation; if the master node SpOnly receiving the consistent voting information of (2f +1) -3 f different node signatures when the timer is ended<PREPARE，H(M)，sn，v，σi>If so, the system state is considered as a general condition; wherein the matching voting information is H (M), sn, v are the same and signature is correct < PREPARE, H (M), sn, v, sigmai>；
(3.2) Master node SpAnd telling other nodes according to the system state broadcast information: under optimistic conditions, the master node SpAggregating received (3f +1) different node signatures
Figure FDA0003386740730000011
Aggre () is a signature aggregation function and broadcasts information
Figure FDA0003386740730000021
To all nodes Si(ii) a Typically, the master node SpAggregating (2f +1) signatures in the received (2f +1) -3 f different node signatures
Figure FDA0003386740730000022
And broadcasting the information
Figure FDA0003386740730000023
Figure FDA0003386740730000024
To all nodes Si。
3. The optimistic fallback-free byzantine fault-tolerant consensus method according to claim 2, wherein the step (4) is specifically:
if node SiReceiving the master node S in the step (3.2)pTransmitted information
Figure FDA0003386740730000025
After the signature is verified, the corresponding request is directly executed and sent<REPLY，res，sn，v，σi”>，σi”←Sign(<H (res), sn, v) to the client C, where res is the result of executing the request.
If node SiReceiving the master node S in the step (3.2)pTransmitted information
Figure FDA0003386740730000026
After the signature is verified, the corresponding request is subjected to a second round of voting, and is sent<COMMIT，H(M)，sn，v，σi’>，σi’←Sign(<H(M)，sn，v，COMMIT>) Giving main jointPoint Sp。
Master node SpUpon receipt of the transmitted consistent voting information < COMMIT, H (M), sn, v, σ signed by (2f +1) different nodesi’>The request is considered to be executable, master node SpAggregating (2f +1) different node signatures
Figure FDA0003386740730000027
And broadcasting the information
Figure FDA0003386740730000028
To all nodes Si。
If node SiReceiving a master node SpTransmitted by
Figure FDA0003386740730000029
Directly executing the request after verifying the two aggregated signatures, and sending<REPLY，res，sn，v，σi”>，σi”←Sign(<H(res)，sn，v>) To the client C.
4. The optimistic fallback-free Byzantine fault tolerant consensus method according to any one of claims 1-3, wherein if a node finds that a master node is Byzantine behaving, broadcasting a view change request message to elect a new master node is achieved by the following sub-steps:
(a1) detecting byzantine behaviour: if the client C does not receive the consistent result information of at least (f +1) different node signatures within the specified time, the broadcast information M is equal to<REQUEST，TX，σc>To all nodes SiWhen node SiStarting a timer after receiving the information, and starting S before the timer is endediHas not received the master node SpAny information sent corresponding to the request M or during the authentication SpByzantine behaviour is discovered upon signing of transmitted information, SiBroadcast VIEW CHANGE request information REQ-VIEW-CHANGE, v, sigmarv i>，σrv iEither ae (REQ-VIEW-CHANGE, v) to request selectionTaking a new main node;
(a2) node SiUpon receipt of consistent view change request information signed by (f +1) different nodes<REQ-VIEW-CHANGE，v，σrv i>Then broadcast a message carrying local message log L<VIEW-CHANGE，v+1，L，σL i>，σL i←Sign(<H(L)>) Indicating that a new master node is ready for election; wherein, L contains all the information of PRE-PREPARE, PREPARED and COMMITTED received by the node;
(a3) constructing a new message log: node SiUpon receipt of consistent < VIEW-CHANGE, v +1, L, σ for (2f +1) different node signaturesL i>Then the node constructs a new message log according to the received (2f +1) message logs and the following rules
Figure FDA00033867407300000210
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 information into the message log
Figure FDA0003386740730000031
And mark it as "to be executed";
b. if there are (f +1) pieces of M, sn, v in the message log and the PRE-PREPARE information broadcast in step (1) with consistent signature and correct signature, and there is the PREPARED information broadcast in step (3.2) with the same sn and correct signature but the corresponding PRE-PREPARE information is different from the (f +1) pieces of consistent PRE-PREPARE information, then the PRE-PREPARE information corresponding to the information with larger view number is selected and added to the message log
Figure FDA0003386740730000032
And mark it as "to vote";
c. if only (f +1) consistent PRE-PREPARE information with correct signature broadcast in the step (1) exists in the message log, adding the PRE-PREPARE information to the message log
Figure FDA0003386740730000033
And mark it as "to vote";
d. if only the PREPARED information broadcasted in the step (3.2) with correct signature exists in the message log, the PRE-PREPARE information corresponding to the information is added to the message log
Figure FDA0003386740730000034
And mark it as "to vote";
the node which is constructed first is used as a new main node Sp’And broadcast
Figure FDA0003386740730000035
Figure FDA0003386740730000036
To all nodes Si；
(a4) View replacement: if node SiReceiving the message broadcast by the step (a3)
Figure FDA0003386740730000037
Verifying signatures and constructs
Figure FDA0003386740730000038
Method of (1) verifying
Figure FDA00033867407300000310
Thereafter, the message is logged according to the following rules
Figure FDA0003386740730000039
The information in (2) is processed:
a. for PRE-PREPARE information marked as 'to-be-executed', directly executing its corresponding transaction request and sending < REPLY, res, sn, v +1, sigmai”’>，σi”’←Sign(<H (res), sn, v +1) to client C, where res is the result of executing the request.
b. For the PRE-PREPARE information marked as 'to be voted', the view is changed to a new view v +1, and the corresponding request is voted for the second time, and the information is sent<COMMIT，H(M)，sn，v+1，σi’>，σi’←Sign(<H(M)，sn，v+1，COMMIT>) For the master node Sp’The main node continues to judge whether the request can be executed according to the second round of voting, if the request can be informed to other nodes by broadcasting information, the other nodes inform the other nodes according to the main node SpThe broadcasted information directly executes the request and feeds 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 true CN114205092A (en) 2022-03-18
CN114205092B 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 (5)

* 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
US20210026842A1 (en) * 2019-07-24 2021-01-28 Vmware, Inc. Flexible byzantine fault tolerant protocol using message delay upper bound for client commit decision
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

Patent Citations (5)

* 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
US20210026842A1 (en) * 2019-07-24 2021-01-28 Vmware, Inc. Flexible byzantine fault tolerant protocol using message delay upper bound for client commit decision
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
王日宏;张立锋;徐泉清;周航: "可应用于联盟链的拜占庭容错共识算法", 计算机应用研究, no. 011 *
蔡亮;李伟;王灿;邱炜伟;杨小虎;徐仁艳;李启雷;尹可挺;匡立中;张帅;宋士正;杨国正;陈晓丰: "高效自主可控区块链基础平台关键技术及应用", 2020年度浙江省登记成果汇编 *

Also Published As

Publication number Publication date
CN114205092B (en) 2023-11-21

Similar Documents

Publication Publication Date Title
CN108667614B (en) Byzantine fault-tolerant method and implementation system thereof
CN114050904B (en) Consensus system and method based on two-level leader node fragmentation structure
CN112417046B (en) Parallelization Bayesian-busy fault-tolerant method applied to block chain consensus mechanism
CN112636905B (en) System and method for extensible consensus mechanism based on multiple roles
CN111555858B (en) Practical Byzantine fault-tolerant consensus method based on block chain type storage
CN115378788B (en) Block chain performance self-adaptive optimization method based on hierarchical consensus and reinforcement learning
CN112019380B (en) Right excitation-based block chain consensus method combining Raft and PBFT algorithm
CN114422513A (en) Block chain consensus method based on Raft-PBFT
CN111064813B (en) Method and device for synchronizing processing messages during block chain consensus processing
CN115051985A (en) Data consensus method of Byzantine fault-tolerant consensus protocol based on dynamic nodes
CN116582543A (en) Consensus method based on slice
CN113992398A (en) Improved PBFT consensus algorithm
CN114140233A (en) Safe cross-slice view conversion method and device for partitioned block chain
CN114095209A (en) Weight-incentive-based alliance chain consensus method and system for main node election
CN114205092A (en) Optimistic byzantine fault-tolerant consensus method without backspacing
CN116232893A (en) Consensus method and device of distributed system, electronic equipment and storage medium
CN114499874B (en) Bayesian-busy-family fault-tolerant consensus optimization method applied to industrial Internet
Ranchal-Pedrosa et al. Basilic: Resilient-optimal consensus protocols with benign and deceitful faults
CN111432028A (en) Service processing method and device based on block chain
CN116455685A (en) PBFT improved consensus method under broadcast network
CN115941680A (en) Flexible fragmentation block chain method and device based on cross-fragmentation Byzantine fault-tolerant algorithm
CN113596115B (en) Network system for realizing multi-node high-performance protocol by using PBFT optimization
CN111818152A (en) Leader election consensus method based on distributed network
CN113949518B (en) Consensus method and system for improving throughput of block chain
Jiang et al. An efficient Byzantine fault-tolerant consensus mechanism based on threshold signature

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