首先,第一阶段是预提议(pre-prepare),这一阶段的主要原因是使用领导可以降低通信复杂度,但是我对其没了解,就不瞎说了。
接着是提议(prepare)阶段,在这一阶段,所有节点需要收到2f+1条提议消息才能够接受消息,这里解释一下为什么是2f+1条:
PBFT假设系统中存在最多f个拜占庭节点,在领导节点是拜占庭节点的情况下,领导节点可以分别给f个正常节点(设为集合a)和f+1个正常节点(设为集合b)预提议不同的两条消息,接着每个拜占庭节点分别给集合a和集合b中的节点投票,此时f个节点会收到其2f条提议消息,f+1个节点会收到2f+1条提议消息,此时为了避免集合a和集合b达成不同的共识,就要使f个节点达不成共识,而f+1个节点可以达成共识,因此,在提议阶段,我们至少需要2f+1条提议消息;
拜占庭节点可能是不投票的,在所有安全节点投票的情况下,节点最多能收到2f+1条提议消息,因此,我们最多只能需要2f+1条提议消息,否则共识无法进行,失去活性。
最后是提交(commit)阶段。我们先假设没有提交阶段,那么少于f个节点接受并且提交了共识信息,而其他节点因为网络延迟等问题触发了视图变更协议,由于视图变更协议需要2f+1条消息,而如果恰好收到的是未提交消息的2f+1个节点发来的消息,那么领导者节点就不会认为该消息已经被提交,从而重新提议一条消息,出现冲突。一次提交阶段是一定需要的。
接下来解释为什么是2f+1条。我们必须保证已经被提交的消息不会因为视图变更而被认为没有被接受(不是安全区块)。为了保证活性,我们的视图变更协议最多收集2f+1条消息。这里除去f个拜占庭节点,我们希望剩下的f+1个节点中能够有至少一个节点给出最新的安全区块(也就是这个被提交的区块),在2f+1个诚实节点中,至少需要有f+1个节点的安全区块是最新的,才能够满足我们的这个希望,也就是至少有f+1个诚实节点是接受了该区块的。那么对于一条被提交的消息,如何保证至少f+1个诚实节点已经接受了区块呢?需要收集2f+1个区块的接受消息再提交区块(其中可能有f个拜占庭节点伪造的接受消息)。
假设不是2f+1条而是2f条,那么就有f+1个节点未接受该区块,在视图变更阶段,这f+1加上f个拜占庭节点,没有一个节点承认被提交的区块是安全区块,所以必须是2f+1条。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)