背景
Andrew Miller 設計了新的共識 HoneyBadgerBFT，論文中提到了BFT共識嚴重依賴時序假設，所造成的脆弱性。
在論文的附錄中，Andrew Miller 介紹了BFT的攻擊方法，本文將對該方法進行翻譯和介紹。
另外本文不再對BFT的時序脆弱性進行論證，詳情可見英文論文或者 中文論文。
正文
PBFT包括兩個主要的工作流
1、網絡環境良好情況下的正常工作模式(網絡節點都同步 而且 leader運行正常)
2、用於更換崩潰leader的view-change模式
正常工作模式
其中模式一，包含三個子協議 Pre-Prepare,Prepare,Commit.
當leader收到客戶端的transaction時，根據transaction廣播pre-prepare消息。
收到pre-prepare消息的節點，廣播prepare消息。
當節點收到2f個preprare消息時，廣播commit消息。
當節點收到2f+1個commit消息時，處理transaction。
view-change模式
當正常工作模式出現超時，共識發生停滯的時候。節點會更換至view-change模式。並將節點本地的view-number++，同時廣播view-change消息
如果節點的正常工作模式沒有出現超時，但是收到了f+1個view-change消息。也會切換到view-change模式，並將節點本地的view-number++，同時廣播view-change消息。
view-change工作模式規定新的leader爲 view-change消息的heightmod 節點總數N。因此新的leader的轉換過程，是在節點集合中循環的。
當節點發現自己就是新的view的leader，而且收到了2f+1個view-change消息時，廣播NEW_VIEW消息。收到的2f+1個view-change消息被組合起來作爲NEW-VIEW消息的proof。
當節點接收到一個 number大於等於自己當前view-number的NEW-VIEW消息時，更新自己的view-number到NEW-VIEW消息的number。
如果節點收到的NEW-VIEWnumber小於自己的當前number,則忽略。
節點進入view-change模式後，維護一個timeout計時器。
每一次view-change工作模式的失敗(例如超時，即在timeout時間內收不到NEW-VIEW消息）都會使timeout計時器的超時時間翻倍。
斷斷續續的正常工作模式將會阻礙PBFT
我們會設計一個惡意的proxy調度器。攔截並延遲發給leader的消息。
下圖展示了攻擊的整個過程
其中
〇 後面的消息是該列表示的節點向外發出的消息
• 後面的消息是該列表示的節點接受到的消息
❌表示收到的消息view已經過時，因而忽略。
紅色區域表示 延時發送
粉色區域表示 延時接受
在每一格的右下角會標註該列節點所處的 view
從圖中我們可以看出。
第一階段
client向0,1,2,3四個節點發出Req。
作爲leader節點的0 向外發出PP 準備挖礦
但是這個PP爲攻擊者抑制住了
所有節點在∆時間內 沒有收到PP，便誤認爲是leader崩潰，進入view-change模式
第二階段
節點0123進入view-change模式
節點0123向外發出V1，試圖更換view，試圖將leader更換爲1
這時候，攻擊者抑制節點1接受V1消息
使得節點023更新到了view1，同時leader也變成了節點1
只有節點1沒有收到V1,於是等待大家推選出新的leader
第三階段
節點1接收到了剛剛被攻擊者抑制的V1消息，發現大家選了自己作爲leader
於是向外宣佈就職，發出消息N1PP1
節點023由於沒有在階段2的時間內收到N1PP1，以爲節點1已經崩潰，無法勝任leader。故向外發送V2宣佈，繼續大選。
節點1收到了V2，發現自己錯過了就職時間，很遺憾，只能附和V2.繼續推選其他leader。
此時攻擊者抑制節點2接受V2消息。
截止當前 節點013都認爲節點2是新的leader
只有身爲leader的節點2還不知情，繼續等待大家選舉leader
第四階段
由於沒有收到leader發出的就職消息，大家以爲節點2已經崩潰。於是發起新的大選V3
節點2也在收到V2後又收到V3，發現自己已經錯過了就職時間。很遺憾但是隻能附和V3
不斷循環上述過程，所有礦工都陷入無盡的大選循環當中，而不從事任何勞動。導致共識停滯。
總結
只要攻擊者能抑制第一個leader發出PP,並順次抑制其他leader接收Vn
整個網絡中的共識就會永久停滯。