一种乐观的不需要回退的拜占庭容错共识方法与流程

1.本发明涉及区块链技术领域，尤其涉及一种乐观的不需要回退的拜占庭容错(byzantine fault tolerance，bft)共识方法。


背景技术：

2.实用拜占庭容错共识算法由米格尔
·
卡斯特罗(miguel castro)和芭芭拉
·
利斯科夫(barbara liskov)于1999年提出，解决了原始拜占庭容错算法效率不高的问题，该方法通过两轮投票使所有节点达成共识，由于节点的投票行为需要广播信息，通信复杂度过高，因此一般系统在达到100左右的节点个数时，性能急剧下降。
3.聚合签名技术可以将多个签名合并成一个签名，并且对聚合签名只需进行一次验证操作，使用该技术，可以将收到的多个投票信息的签名进行聚合，聚合后的签名即可作为多个节点签名的证明。利用该特性可以一定程度上降低通信复杂度，但是想要节点达成共识，仍然需要进行两轮的投票。
4.投机拜占庭容错共识算法由罗摩克里希纳
·
科特拉(ramakrishna kotla)于2007年提出，该算法使用聚合签名技术效降低通信复杂度，并针对无拜占庭错误场景对算法进行优化，投机地采用更简单地共识算法快速达成共识，而不需要总是进行两轮投票，但是当快速共识失效时，需要对系统的状态进行回退操作。
5.现有的拜占庭容错算法要么需要两轮投票，要么采用投机执行的方法来减少投票轮数，而引入了需要状态回退操作的问题，如何提高共识过程的效率，仍是一个有待解决的问题。


技术实现要素：

6.本发明的目的在于针对现有技术的不足，提供一种乐观的不需要回退的拜占庭容错共识方法。
7.本发明的目的是通过以下技术方案来实现的：一种乐观的不需要回退的拜占庭容错共识方法，包括以下步骤：
8.(1)客户端c在区块链系统中发起交易并发送请求m＝《request,tx,σc》,σc←
sign(《request,tx》)给主节点s
p
，同时客户端c设定计时器，其中，σ表示签名，下标表示签名者，sign()是签名函数，tx为客户端请求执行的交易；
9.主节点s
p
收到请求m并验证σc签名后，广播《pre-prepare,m,sn,v,σ
p
》,σ
p
←
sign(《h(m),sn,v》)给所有节点si，i＝1,
…
,(3f 1)；节点只处理视图编号与节点所处视图编号一致的信息，同时主节点s
p
设定计时器并等待节点发来的投票信息。其中，(3f 1)为区块链系统中节点个数，包括至多f个拜占庭节点和至少(2f 1)个正确节点；v是节点s
p
所处视图的视图编号，sn是主节点分配给请求m的编号；
10.(2)节点si收到步骤(1)中发来的《pre-prepare,m,sn,v,σ
p
》，验证σ
p
后对其进行投票发送《prepare,h(m),sn,v,σi》,σi←
sign(《h(m),sn,v》)给主节点s
p
；
11.(3)主节点s
p
根据收到的投票信息数量判断是否为乐观情况并广播信息告诉其他节点，其中，若主节点s
p
收到一致的投票信息数量为(3f 1)，则为乐观情况，若主节点s
p
收到一致的投票信息数量为(2f 1)～3f，则为一般情况；
12.(4)若步骤(3)中判断为一般情况节点si根据主节点s
p
广播的信息进行第二轮投票，若为乐观情况，节点si根据主节点s
p
广播的信息直接执行请求并将结果反馈给客户端c；第二轮投票后主节点s
p
依据投票结果判断是否可以执行请求，若可以广播信息告诉其他节点，其他节点根据主节点s
p
广播的信息直接执行请求并将结果反馈给客户端c。
13.在步骤(1)～(4)执行过程中，若节点发现主节点存在拜占庭行为，则广播视图更改请求信息以选举新的主节点，在新的主节点下完成后续共识。
14.进一步地，所述步骤(3)通过以下子步骤来实现：
15.(3.1)判断系统状态：主节点s
p
在计时器结束前，一旦收到来自(3f 1)个不同节点签名的一致的投票信息，则认为系统状态为乐观情况；若主节点s
p
在计时器结束时只收到(2f 1)～3f个不同节点签名的一致的投票信息《prepare,h(m),sn,v,σi》，则认为系统状态为一般情况；其中，一致的投票信息为h(m),sn,v相同且签名正确的《prepare,h(m),sn,v,σi》。
16.(3.2)主节点s
p
根据系统状态广播信息告诉其他节点：乐观情况下，主节点s
p
将收到的(3f 1)个不同节点签名进行聚合aggre()为签名聚合函数，并广播信息给所有节点si；一般情况下，主节点s
p
将收到的(2f 1)～3f个不同节点签名中的(2f 1)个签名进行聚合并广播信息并广播信息给所有节点si。
17.进一步地，所述步骤(4)具体为：
18.若节点si收到步骤(3.2)中主节点s
p
发送的信息验证签名后直接执行其对应的请求，并发送《reply,res,sn,v,σ
i”》,σi”←
sign(《h(res),sn,v)给客户端c，其中，res为执行请求的结果；
19.若节点si收到步骤(3.2)中主节点s
p
发送的信息验证签名后，对其对应的请求进行第二轮投票，发送《commit,h(m),sn,v,σ
i’》,σi’←
sign(《h(m),sn,v,commit》)给主节点s
p
；
20.主节点s
p
一旦收到发来的(2f 1)个不同节点签名的一致的投票信息《commit,h(m),sn,v,σ
i’》，则认为该请求可以被执行，主节点s
p
将(2f 1)个不同节点签名聚合并广播信息给所有节点si；
21.若节点si收到主节点s
p
发送的验证两个聚合签名后直接执行该请求，并发送《reply,res,sn,v,σ
i”》，σi”←
sign(《h(res),sn,v》)给客户端c。
22.进一步地，所述若节点发现主节点存在拜占庭行为，则广播视图更改请求信息以选举新的主节点通过以下子步骤来实现：
23.(a1)检测拜占庭行为：如果客户端c在规定时间内没有收到至少(f 1)个不同节点签名的一致的结果信息，则广播信息m＝《request,tx,σc》给所有节点si，当节点si收到该信
息后开启计时器，若计时器结束前si没有收到主节点s
p
发来的对应请求m的任何信息或在验证s
p
发送的信息的签名时发现拜占庭行为，si广播视图更改请求信息《req-view-change,v,σ
rvi
》,σ
rvi
←
sign(req-view-change,v)以请求选举新的主节点；
24.(a2)节点si一但收到(f 1)个不同节点签名的一致的视图更改请求信息《req-view-change,v,σ
rvi
》，则广播一条携带本地消息日志l的信息《view-change,v 1,l,σ
li
》,σ
li
←
sign(《h(l)》)表示已准备好选举新的主节点；其中l包含节点收到的所有pre-prepare、prepared、committed信息；
25.(a3)构造新的消息日志：节点si一旦收到(2f 1)个不同节点签名的一致的《view-change,v 1,l,σ
li
》，则该节点根据收到的(2f 1)个消息日志和以下规则构造新的消息日志
26.a、若消息日志中存在步骤(4)或步骤(3.2)中广播的committed信息，则将该信息对应的pre-prepare信息添加到中，并且将其标记为“待执行”；
27.b、若消息日志中存在(f 1)个m,sn,v都一致且签名正确的步骤(1)中广播的pre-prepare信息，同时存在步骤(3.2)中广播的拥有相同sn且签名正确的prepared信息，但其对应的pre-prepare信息不同于这(f 1)个一致的pre-prepare信息，则选择拥有视图编号较大的信息对应的pre-prepare信息添加到中，并且将其标记为“待投票”；
28.c、若消息日志中只存在(f 1)个一致的且签名正确的步骤(1)中广播的pre-prepare信息，则将该pre-prepare信息添加到中，并且将其标记为“待投票”；
29.d、若消息日志中只存在签名正确的步骤(3.2)中广播的prepared信息，则将该信息对应的pre-prepare信息添加到中，并且将其标记为“待投票”；
30.最先构造完成的节点作为新的主节点s
p’并且广播并且广播给所有节点si；
31.(a4)视图更换：若节点si收到步骤(a3)广播的消息验证签名并用构造的方法验证后，根据以下规则对消息日志中的信息进行处理：
32.a、针对标记为“待执行”的pre-prepare信息，直接执行其对应的交易请求并发送《reply,res,sn,v 1,σi”’
》,σi”’←
sign(《h(res),sn,v 1)给客户端c，其中，res为执行请求的结果；
33.b、针对标记为“待投票”的pre-prepare信息，更换到新的视图v 1，并对其对应的请求进行第二轮投票，发送《commit,h(m),sn,v 1,σ
i’》,σi’←
sign(《h(m),sn,v 1,commit》)给主节点s
p’，主节点根据第二轮投票继续判断是否可以执行请求，若可以广播信息告诉其他节点，其他节点根据主节点s
p
广播的信息直接执行请求并将结果反馈给客户端c。
34.本发明的有益效果是，在系统中不存在拜占庭行为时，即乐观情况下只需要进行一轮投票即可使节点达成共识，有效降低了确认延迟，系统中信息量会大幅度减少，吞吐量会有明显提升。并且在一般情况下不需要进行状态的回退，仅需在第一轮投票的基础上进行第二轮投票，实现方法简单，不容易出错，代码质量能得到保证。
附图说明
35.图1是该发明在乐观情况下的通信模式。
36.图2是该发明在一般情况下的通信模式。
具体实施方式
37.下面根据附图详细说明本发明。
38.本发明乐观的不需要回退的拜占庭容错共识方法，包括以下步骤：
39.(1)主节点广播提案。
40.设系统中有(3f 1)个节点，包括至多f个拜占庭节点和至少(2f 1)个正确节点，使用bls(boneh-lynn-shacham)签名算法对消息进行签名，实现聚合签名。客户端c发送请求m＝《request,tx,σc》(其中σc←
sign(《request,tx》)是客户端的签名信息，sign()是签名函数，tx为客户端请求执行的交易)给主节点s
p
，同时客户端c设定计时器(计时器的大小可根据网络情况设定合适的值)，主节点s
p
收到m并验证σc后，广播《pre-prepare,m,sn,v,σ
p
》给所有节点si(i可以等于p，即广播给包括自己的所有节点)，其中σ
p
←
sign(《h(m),sn,v》)是主节点s
p
的签名信息，同时主节点s
p
设定计时器(计时器的大小可根据网络情况设定合适的值)并等待节点发来的投票信息(其中v是节点s
p
所处视图的视图编号，sn是主节点分配给请求m的编号，h()为哈希函数，所有节点对每一个收到的消息都进行视图编号判断，节点只处理视图编号与节点所处视图编号一致的信息)。
41.(2)第一轮投票(供步骤(3)使用)。
42.节点si收到步骤(1)中发来的《pre-prepare,m,sn,v,σ
p
》，验证σ
p
后对其进行投票发送《prepare,h(m),sn,v,σi》给主节点s
p
(其中σi←
sign(《h(m),sn,v》)是节点si的签名信息)。
43.(3)主节点s
p
根据收到的投票信息数量判断是否为乐观情况并广播信息告诉其他节点。
44.该步骤是本发明的核心，分为以下子步骤。
45.(3.1)判断系统状态。
46.第一轮投票后，主节点在规定的时间内会收到节点发来的投票信息(包括它自己的)。主节点s
p
在计时器结束前，一旦收到来自(3f 1)个不同节点签名的一致的投票信息《prepare,h(m),sn,v,σi》(要求对应的h(m),sn,v相同，并且签名正确)，则认为系统状态为乐观情况。若主节点s
p
在计时器结束时没有收到来自(3f 1)个，但收到(2f 1)～3f个不同节点签名的一致的投票信息《prepare,h(m),sn,v,σi》(要求对应的h(m),sn,v相同，并且签名正确)，则认为系统状态为一般情况。若主节点s
p
在计时器结束时收到少于(2f 1)个不同节点签名的一致的投票信息《prepare,h(m),sn,v,σi》，则不做处理。
47.(3.2)主节点根据系统状态执行对应操作。
48.乐观情况下，主节点s
p
将签名进行聚合({σi}为(3f 1)个签名的集合，aggre()为签名聚合函数)，并广播信息给所有节点si。一般情况下，主节点s
p
将签名进行聚合({σi}为(2f 1)～3f个签名中的(2f 1)个签名的集合，aggre()为签名聚合函数)，并广播信息
给所有节点si。
49.(4)节点根据步骤(3)中发来的信息判断进行第二轮的投票或执行请求。
50.该步骤是本发明的核心，具体如下：
51.若节点si收到步骤(3.2)中主节点s
p
发送的信息则验证签名后直接执行其对应的请求，并发送《reply,res,sn,v,σ
i”》给客户端c(其中σi”←
sign(《h(res),sn,v)，res为执行请求的结果)，如图1所示。
52.若节点si收到步骤(3.2)中主节点s
p
发送的信息则验证签名后，对其对应的请求进行第二轮投票，如图2所示，发送《commit,h(m),sn,v,σ
i’》(其中σi’←
sign(《h(m),sn,v,commit》))给主节点s
p
。主节点判断第二轮投票后是否可以执行请求：
53.主节点s
p
一旦收到(2f 1)个不同节点签名的一致的第二轮投票信息《commit,h(m),sn,v,σ
i’》，则认为该请求可以被执行，主节点s
p
将签名聚合({σ
i’}为(2f 1)个签名的集合)，并广播信息给所有节点si(为对应步骤(3.2)中prepared信息中的聚合签名)。
54.若节点si收到主节点s
p
发送的验证签名后直接执行该请求，并发送《reply,res,sn,v,σ
i”》给客户端c(其中σi”←
sign(《h(res),sn,v)，res为执行请求的结果)。
55.整个过程中若节点发现主节点存在拜占庭行为，则广播视图更改请求信息以选举新的主节点。
56.该步骤是本发明的核心，分为以下子步骤。
57.(a1)检测拜占庭行为。
58.如果客户端c在规定时间内没有收到至少(f 1)个不同节点签名的一致的信息《reply,res,sn,v,σ
i”》，则广播信息m＝《request,tx,σc》给所有节点si，当节点si收到该信息后开启计时器，若计时器结束时si没有收到主节点s
p
发来对应该请求的任何信息，则认为当前主节点s
p
存在拜占庭行为，si广播视图更改请求信息《req-view-change,v,σi》以请求选举新的主节点。若在验证s
p
发送的信息的签名时发现拜占庭行为即验证不通过，同样发送《req-view-change,v,σ
rvi
》(其中v是节点si的当前视图编号，σ
rvi
←
sign(《req-view-change,v》))。
59.(a2)节点si一但收到(f 1)个不同节点签名的一致的视图更改请求信息《req-view-change,v,σ
rvi
》，则广播一条携带本地消息日志l的信息《view-change,v 1,l,σ
li
》表示已准备好选举新的主节点(其中l包含节点收到的所有pre-prepare、prepared、committed信息，σ
li
←
sign(《h(l)》))。
60.(a3)构造消息日志。
61.节点si一旦收到(2f 1)个不同节点签名的一致的《view-change,v 1,l,σ
li
》，则该节点根据收到的(2f 1)个消息日志和以下规则构造新的消息日志
62.a、若消息日志中存在步骤(4)或步骤(3.2)中广播的committed信息，则将该信息对应的pre-prepare信息添加到中，并且将其标记为“待执行”。
63.b、若消息日志中存在(f 1)个一致的且签名正确的步骤(1)中广播的pre-prepare信息(对应的m,sn,v都相同)，同时存在步骤(3.2)中广播的拥有相同sn且签名正确的prepared信息，但其对应的pre-prepare信息不同于这(f 1)个一致的pre-prepare信息，则选择拥有视图编号较大的信息对应的pre-prepare信息添加到中，并且将其标记为“待投票”。
64.c、若消息日志中只存在(f 1)个一致的且签名正确的步骤(1)中广播的pre-prepare信息，则将该pre-prepare信息添加到中，并且将其标记为“待投票”。
65.d、若消息日志中只存在签名正确的步骤(3.2)中广播的prepared信息，则将该信息对应的pre-prepare信息添加到中，并且将其标记为“待投票”。
66.最先构造完成的节点作为新的主节点s
p’并且广播给所有节点si(其中
67.(a4)视图更换。
68.若节点si收到步骤(a3)广播的消息验证签名并用构造的方法验证后，根据以下规则对消息日志中的信息进行处理：
69.a、针对标记为“待执行”的pre-prepare信息，直接执行其对应的交易请求并发送《reply,res,sn,v 1,σi”’
》给客户端c，其中σi”’←
sign(《h(res),sn,v 1》)，res为执行请求的结果)。
70.b、针对标记为“待投票”的pre-prepare信息，更换到新的视图v 1，并对其对应的请求进行第二轮投票，发送《commit,h(m),sn,v 1,σ
i’》给主节点s
p’(其中σi’←
sign(《h(m),sn,v 1,commit》))，然后主节点判断第二轮投票后是否可以执行请求，若可以则广播信息告诉其他节点，其他节点根据主节点s
p
广播的信息直接执行请求并将结果反馈给客户端c。
71.安全性证明(safety)
72.要证明该方法的安全性，即证明：如果正确的节点si在视图v中以编号sn执行交易请求tx，则不会有正确的节点sj在视图v’≥v中以编号sn执行不同于tx的交易请求tx’。
73.假设正确节点si在视图v以编号sn执行了交易请求tx，则si可能收到具体实施方式中步骤(4)或步骤(3.2)中广播的committed信息：
74.若si在视图v收到步骤(3.2)中广播的则(3f 1)个节点在视图v收到了交易请求tx对应的pre-prepare信息，下面分别分析正确节点sj在视图v和视图v’≥v的表现：
75.(a)当正确节点sj处于视图v时，因为正确节点sj已经收到当前主节点s
p
发送的编号为sn的交易请求tx对应的pre-prepare信息，所以sj不会接受当前主节点s
p
发送的拥有相同的sn但不同于tx的交易请求tx’对应的pre-prepare信息。因此，在相同视图下，正确节点sj不会以编号sn执行不同于tx的交易请求tx’。
76.(b)正确节点sj在切换到下一个视图之前，要求新的主节点s
p’收到至少(2f 1)个view-change信息，其中包含至少(f 1)个正确节点的消息日志，在新的主节点s
p’构造新的消息日志时，可能对应上述步骤(a3)构造消息日志步骤中的情况(a)(b)(c)，如果出现情况
(a)则正确节点sj会在切换到下一个视图之前以编号sn执行tx；如果出现情况(b)(c)，由于在视图v’≥v中至多有2f个节点对编号同为sn的tx’进行投票，即不会形成对应tx’的prepared信息，更不会生成对应tx’的committed信息，因此在新的视图中正确节点sj不会以编号sn执行不同于tx的交易请求tx’，而会根据new-view信息继续对tx进行投票和执行。
77.若si在视图v收到步骤(4)中广播的信息则至少(2f 1)个节点在视图v收到了一致的pre-prepare和prepraed信息，其中包含至少(f 1)个正确节点，下面分别分析正确节点sj在视图v和视图v’≥v的表现：
78.(a)当正确节点sj处于视图v时，因为已经至少有(f 1)个正确节点接受了当前主节点s
p
发送的编号为sn的交易请求tx对应的pre-prepare信息，并且不会接受当前主节点s
p
发送的拥有相同的sn但不同于tx的交易请求tx’对应的pre-prepare信息，所以至多有2f个节点对编号为sn的交易请求tx’进行投票，所以不会形成对应tx’的prepared信息，更不会形成对应tx’的committed信息，即在相同视图下，正确节点sj不会以编号sn执行不同于tx的交易请求tx’。
79.(b)正确节点sj在切换到下一个视图之前，因为至少有一个正确节点记录了prepared信息到消息日志中，所以新的主节点s
p’构造新的消息日志时，可能对应上述步骤(a3)构造消息日志步骤中的情况(a)(b)(d)，如果出现情况(a)则sj会在切换到下一个视图之前以编号sn执行tx；如果出现情况(b)(d)，由于在视图v’≥v中至多有2f个节点对编号同为sn但不同于tx的tx’进行投票，所以不会形成对应tx’的prepared信息，更不会形成对应tx’的committed信息。因此在新的视图中正确节点sj不会以编号sn执行不同于tx的交易请求tx’，而会根据new-view信息继续对tx进行投票和执行。
80.可用性证明(liveness)
81.证明可用性，即证明：若客户端c在区块链系统中发起交易请求tx，则客户端最终会收到至少(f 1)个关于tx的一致的执行结果。
82.我们约定一旦客户端收到(f 1)个一致的执行结果，则视该笔交易请求完成。如果在视图v中，主节点s
p
是正确节点，并且网络状况不是异步网络，则称当前视图是稳定的。下面从视图处于的状态来分析和证明可用性：
83.当视图为稳定状态时，正确的主节点s
p
广播pre-prepare信息后，经过足够长的时间的等待，一定会生成一个相应的committed信息，最终所有正确节点会执行该committed信息对应的交易请求，并反馈给客户端c。
84.当视图为不稳定状态时，客户端发起的交易请求长时间得不到完成会引起视图切换，我们假设(2f 1)个节点广播了view-change信息，下面从新的主节点s
p’是否为正确节点分析和证明可用性：
85.(a)新的主节点s
p’是正确节点，并且所有正确节点都收到了正确的new-view信息，所有正确节点将成功切换到新的稳定的视图。
86.(b)新的主节点s
p’是错误节点，并且所有正确节点都没有收到正确new-view信息，则引起新的视图切换。
87.(c)新的主节点s
p’是错误节点，并且只有一部分正确节点收到正确的new-view信息，在这种情况下，若错误节点遵循共识方法规则，可使这部分收到正确的new-view信息的正确节点进入不稳定的视图；若错误节点没有遵循共识方法规则，正确节点最终会发起新
的视图切换请求，即不论错误节点是否遵循共识方法规则，都会引起新的视图切换。
88.在情况(b)(c)中，新的视图更换请求发起，会再次让系统进入(a)(b)(c)的状态之一。由于至多有f个错误节点，所以至多进行(f 1)次视图切换，就会选到一个正确的节点作为新的主节点，从而切换到稳定的视图。因此，系统最终将达到情况(a)，即进入一个稳定的视图，从而保证可用性。