有小朋友問PBFT的基本問題：“PBFT為何需要COMMIT階段”？整理舊日筆記如下：
需要幾個階段云云，一定不能拋開VIEW CHANGE邏輯孤立地去看，一定一定需要結合起來才能明白。
先看PBFT目前的邏輯中，如果某個honest node收到了(2f+1)個COMMIT消息后（對應的交易假設是txnA），據此認定共識達成并執(zhí)行，然后由于網絡的異步性引發(fā)眾多其他節(jié)點超時，最終發(fā)生VIEW CHANGE會如何。
VIEW CHANGE過程中會有 (2f+1)個節(jié)點提供VIEW_CHG消息，每個VIEW_CHG消息里面又打包了這個節(jié)點見到過的、屬于不同VIEW的各類消息（PRE_PREPARE，PREPARE等等），新的leader會試圖根據這些VIEW_CHG消息恢復原先view里面做了半拉的事情，以一種確保一致的方式替前任背完鍋后再宣布進入自己的VIEW，并提出自己的pre_prepare。
所謂COMMON WORKFLOW和VIEW CHANGE的配合，就是說COMMON WORKFLOW里面要為可能的VIEW CHANGE保存足夠的信息，而VIEW CHANGE必須充分利用這些信息完美地替前任擦干凈屁股。。。兩者一定是互相配合。
回到剛才的討論。只要有一個honest節(jié)點收到了view=v的(2f+1)個COMMIT消息（對應的交易假設是txnA）后，據此認定共識達成并執(zhí)行，后續(xù)的VIEW CHANGE應該能告訴其他節(jié)點：view=v共識的交易是txnA，不可導致其他人認為共識到txnB或者NULL。那么在現在的PBFT協議中，這些信息是足夠的：?
（觀察一）有一個honest node收到了view=v的(2f+1)個COMMIT消息（對應的交易假設是txnA）--->? 有(2f+1)個節(jié)點發(fā)出了對應txnA的COMMIT消息?---> 至少有(f+1)個honest節(jié)點發(fā)出了對應txnA的COMMIT消息?--->有(f+1)個honest節(jié)點收到了(2f+1)個對應txnA的PREPARE消息，記錄這(f+1)個honest節(jié)點構成的節(jié)點集為QUORUM_A
（2f+1）個提供VIEW_CHG消息的節(jié)點記為QUORUM_B，根據抽屜原理，QUORUM_A和QUORU_B的交集至少包含了一個honest節(jié)點，這個節(jié)點可以提供前一個VIEW中可能被最終提交的交易信息txnA（證據是2f+1個對應于它的prepare消息）
（觀察二）除了對應txnA的(2f+1)個PREPARE消息之外，沒有任何節(jié)點有能力給出(2f+1）個對應其他txnB的（2f+1）個PREPARE消息：因為如果還存在另外(2f+1)個對應于txnB的PREPARE消息，一定有一個honest節(jié)點又發(fā)了對應txnA的PREPARE消息，又發(fā)了對應txnB的PREPARE消息，而這個是不可能的。
（觀察三）結合上述二者，QUORUM_B中至少包含了前一個VIEW鐘可能被最終提交的交易信息txnB，且不可能存在矛盾的txnB，因此據此去恢復翻車現場是可行的且不會導致分叉。
因此，上述分析說明的是，有了COMMIT階段的協議，配合正確的VIEW CHANGE算法，是正確的。
反過來，如果簡單去掉COMMIT階段，而VIEW CHANGE算法仍然是這樣會如何？答案是這個爛攤子是沒法收拾的，因為不存在上述唯一正確的信息。
1）假設view = v 時候的惡意節(jié)點集合是HE， 其中惡意leader給honest節(jié)點x 和包括 f個其他honest節(jié)點的集合HX發(fā)送了 對應 txnA 的 PRE_PREPARE消息，給包括f個額外的honest節(jié)點集合 HY 發(fā)送了對應 txnB的 PRE_PREPARE消息；?
2）HE, HX和x自己給x發(fā)送了對應txnA的( 2f+1）個PREPARE消息，而節(jié)點x據此認為共識完成（是txnA）
3） 由于異步網絡的緣故，HX和HB的其他節(jié)點沒收到足夠的PREPARE消息（包括對應txnA的）
4） 異步網絡引發(fā)VIEW CHANGE
5） 提供（2f+1）個 VIEW_CHG消息的節(jié)點可能不包含上述節(jié)點x，可能是 HX中的1個節(jié)點(支持txnA)，加上惡意節(jié)點集合HE，honest節(jié)點集合HY（支持txnB），這樣在VIEW_CHG消息集合中占優(yōu)勢的信息反而是txnB，這個時候新的LEADER應該如何決策？算法該如何設計？
上述分析說明的是，簡單在PBFT中去掉COMMIT階段的協議，VIEW CHANGE算法應該如何設計就不清楚了。
