有小朋友问PBFT的基本问题：“PBFT为何需要COMMIT阶段”？整理旧日笔记如下：

需要几个阶段云云，一定不能抛开VIEW CHANGE逻辑孤立地去看，一定一定需要结合起来才能明白。

先看PBFT目前的逻辑中，如果某个honest node收到了(2f+1)个COMMIT消息后（对应的交易假设是txnA），据此认定共识达成并执行，然后由于网络的异步性引发众多其他节点超时，最终发生VIEW CHANGE会如何。

VIEW CHANGE过程中会有 (2f+1)个节点提供VIEW_CHG消息，每个VIEW_CHG消息里面又打包了这个节点见到过的、属于不同VIEW的各类消息（PRE_PREPARE，PREPARE等等），新的leader会试图根据这些VIEW_CHG消息恢复原先view里面做了半拉的事情，以一种确保一致的方式替前任背完锅后再宣布进入自己的VIEW，并提出自己的pre_prepare。

所谓COMMON WORKFLOW和VIEW CHANGE的配合，就是说COMMON WORKFLOW里面要为可能的VIEW CHANGE保存足够的信息，而VIEW CHANGE必须充分利用这些信息完美地替前任擦干净屁股。。。两者一定是互相配合。

回到刚才的讨论。只要有一个honest节点收到了view=v的(2f+1)个COMMIT消息（对应的交易假设是txnA）后，据此认定共识达成并执行，后续的VIEW CHANGE应该能告诉其他节点：view=v共识的交易是txnA，不可导致其他人认为共识到txnB或者NULL。那么在现在的PBFT协议中，这些信息是足够的： 

（观察一）有一个honest node收到了view=v的(2f+1)个COMMIT消息（对应的交易假设是txnA）--->  有(2f+1)个节点发出了对应txnA的COMMIT消息 ---> 至少有(f+1)个honest节点发出了对应txnA的COMMIT消息 --->有(f+1)个honest节点收到了(2f+1)个对应txnA的PREPARE消息，记录这(f+1)个honest节点构成的节点集为QUORUM_A

（2f+1）个提供VIEW_CHG消息的节点记为QUORUM_B，根据抽屉原理，QUORUM_A和QUORU_B的交集至少包含了一个honest节点，这个节点可以提供前一个VIEW中可能被最终提交的交易信息txnA（证据是2f+1个对应于它的prepare消息）

（观察二）除了对应txnA的(2f+1)个PREPARE消息之外，没有任何节点有能力给出(2f+1）个对应其他txnB的（2f+1）个PREPARE消息：因为如果还存在另外(2f+1)个对应于txnB的PREPARE消息，一定有一个honest节点又发了对应txnA的PREPARE消息，又发了对应txnB的PREPARE消息，而这个是不可能的。

（观察三）结合上述二者，QUORUM_B中至少包含了前一个VIEW钟可能被最终提交的交易信息txnB，且不可能存在矛盾的txnB，因此据此去恢复翻车现场是可行的且不会导致分叉。

因此，上述分析说明的是，有了COMMIT阶段的协议，配合正确的VIEW CHANGE算法，是正确的。

反过来，如果简单去掉COMMIT阶段，而VIEW CHANGE算法仍然是这样会如何？答案是这个烂摊子是没法收拾的，因为不存在上述唯一正确的信息。

1）假设view = v 时候的恶意节点集合是HE， 其中恶意leader给honest节点x 和包括 f个其他honest节点的集合HX发送了 对应 txnA 的 PRE_PREPARE消息，给包括f个额外的honest节点集合 HY 发送了对应 txnB的 PRE_PREPARE消息； 

2）HE, HX和x自己给x发送了对应txnA的( 2f+1）个PREPARE消息，而节点x据此认为共识完成（是txnA）

3） 由于异步网络的缘故，HX和HB的其他节点没收到足够的PREPARE消息（包括对应txnA的）

4） 异步网络引发VIEW CHANGE

5） 提供（2f+1）个 VIEW_CHG消息的节点可能不包含上述节点x，可能是 HX中的1个节点(支持txnA)，加上恶意节点集合HE，honest节点集合HY（支持txnB），这样在VIEW_CHG消息集合中占优势的信息反而是txnB，这个时候新的LEADER应该如何决策？算法该如何设计？

上述分析说明的是，简单在PBFT中去掉COMMIT阶段的协议，VIEW CHANGE算法应该如何设计就不清楚了。