除了狀態變數viewNumber(從1開始，儲存它投票給預提交的最高QC)、prepareQC(從nil開始)、lockedQC(從nil開始，儲存它投票給提交的最高QC)之外，每個參與者在本地儲存一個掛起命令樹。當“新觀點”或“新一輪”開始時，公共功能從當前參與者中確定領導者。

每個參與者將其預先的QC傳送給領導者，當領導者收到客戶的操作請求m時，n個參與者執行BFT協議的4個階段。HotStuff的關鍵創新來自以前的解決方案星型通訊網路允許HotStuff BFT/LibraBFT在降低通訊複雜度的同時提高整體複雜度，從而達到一致。需要注意的關鍵創新是:1.HotStuff參與者在p2p通道（星型拓撲通訊網路）中向領導參與者傳送簽名訊息。

2.使用門限數字簽名方案，無論領導者是正確的還是錯誤的，HotStuff都能實現線性驗證器的複雜度。也許最相關的是：PaceMaker是最初的HotStuff論文提出的實現輪同步的功能，但該檔案缺乏明確的實現細節。因此，我們可以看看LibraBFT是如何實現它的：當一個參與者放棄一輪時，它就會用迴圈入口證書廣播一個超時訊息。他們希望這能使所有(誠實的)參與者在傳輸延遲的範圍內將r輪起來。收集參與者超時訊息的仲裁後，將形成超時證書，並實現輪同步。可靠領導者的重要性HotStuff BFT協議的漏洞特別強調了訊息傳播的重要性，因為它缺乏一個明確的決策訊息傳播過程。當領導者不能可靠地在HotStuff中廣播決定訊息時，麻煩就出現了。考慮以下場景：

根據協議，領導者的任務是將路徑擴充套件到(a0 -> a1 -> … -> at -> b)。假設執行過程沒有任何問題，我們繼續下一個檢視v+1。我們期望領導者將命令傳播給所有參與者，所有參與者都應該執行與擴充套件葉節點b和c相關的命令。HotStuff BFT協議規定“在實踐中，落後的接收者可以透過從其他副本中提取丟失的節點來趕上。”這意味著，在檢視v+1結束時，落後的參與者可以獲取對應於(a0 -> a1 -> … -> at -> b -> c).的prepareQC。然而，這個試圖追趕的參與者無法知道是否所有的參與者都實際執行了這些命令（即，領導者是否將節點b的命令傳播給每個人、1個節點或某個子集）。根據HotStuff BFT協議，樹上的節點只包含父節點的雜湊值和客戶端命令。因此，由每個參與者維護的葉節點不包含有關命令是否已執行的資訊。最後，本分析證明了HotStuff的最初概述使網路上的參與者容易受到不一致性的影響。這裡的教訓是，考慮是否在樹節點本身中執行了一個給定的命令是很重要的。