使用PBFT和Vector Clock解決區塊鏈時序問題

摘要： 背景 如果用區塊鏈來記賬，就會涉及到一個分散式時序的問題。當交易在不同區塊時，我們很容易依賴各自相關的塊高度來判斷時序問題。但是為了提高區塊鏈的吞吐，就必須進行批出來，這樣一來，出塊的間隔就會增大，如果相關的兩個事件，事件間隔特別短，出現在同一個塊內時，如果判斷時序問題？因為通常的P2P傳...

背景

如果用區塊鏈來記賬，就會涉及到一個分散式時序的問題。當交易在不同區塊時，我們很容易依賴各自相關的塊高度來判斷時序問題。但是為了提高區塊鏈的吞吐，就必須進行批出來，這樣一來，出塊的間隔就會增大，如果相關的兩個事件，事件間隔特別短，出現在同一個塊內時，如果判斷時序問題？因為通常的P2P傳播很容易亂序，同時出塊的節點地理位置漂移很大，我們無條件信任出塊節點的排序？我想一般場景可以這樣，對時序非常敏感的場景就不能這樣信任某一個節點的排序了。

為什麼用PBFT

為了解決時序問題，那麼我們就需要對每個交易產生的時間達成一個共識，這裡我們使用 PBFT ，其比 DPOS 、 POW 等共識演算法的優勢就是：

• 在共識過程中，其能第一時間將交易傳播到主要節點上，這是 DPOS 、 POW 等不具備的。這是非常重要的，如果自己都不能第一時間收到交易，那還怎麼參與共識？只能條件信任他人了。
• 它能夠實時識別作弊者，並且可以實時糾錯和懲罰。 DPOS 、 POW 等都是後知後覺的，而且懲罰滯後的，有些都放棄了懲罰，依賴博弈論使其放棄作弊，然後博弈論需要每個參與者都是 精緻的利己主義者 ，然後在 EOS 執行這麼久後，博理論並不能100%發揮其上帝法則，因為愚昧的大多數，其每一個決策並不一定有正收益，反而被各種集體利用蠱惑。
• PBFT 其通訊複雜度是 $O(n^2)$ ，並且需要一個確定是參與者範圍，比較適合聯盟鏈場景。

時序邏輯

首先，每個參與者各自維護一個本地單調時鐘，該單調時鐘基於物理時鐘，但是不能回退。然後每個參與者維護一個 Vector ，記錄著每個參與者的時間戳，初始值可以都為零。比如我們有4個參與者

$P_1$ 、 $P_2$ 、 $P_3$ 、 $P_4$

：

PRE-PREPARE ：當有客戶端請求

$Tx_A$ 到達時， $P_1$ 節點在將當前時間戳 $t_{A1}$ 新增到 $Tx_A$ 中並且進行簽名。然後將 $Tx_A$ 傳送給各個參與者，收到 $Tx_A$ 的參與者，驗證前面合法性、驗證 $P_1$ 時間戳的單調性，並且將時間戳 $Tx_A$

記錄到本地。

PREPARE ：如果都OK，各自將本地的時間戳都附加到

$Tx_A$

上，並且簽名，然後傳送給各個參與者。

每個參與者收到其他人的訊息後，根據交易信息進行合併，校驗各個參與者的時間單調性、簽名等，此時，每個參與者的本地都收集到一個關於交易

$Tx_A$ 的一個 Vector Clock $[T_{P_1} = t_{A1},T_{P_2} = t_{A2},T_{P_3}=t_{A3},T_{P_4}=t_{A4}]$ 。這裡我們忽略掉 COMMIT 階段，因為我們需要收集每個參與者的時序，如果還需要其他行為，可以繼續 COMMIT

階段。

REPLY ：我們可以選用

$Reply_i$ 或者 $Reply_j$

方案，區別就是是否響應發起者。

比較邏輯

根據上面的流程，我們對於每個交易

$Tx_i$ 都會有一個對應的 Vector Clock $[T_{P_1} = t_{i1},T_{P_2} = t_{i2},T_{P_3}=t_{i3},T_{P_4}=t_{i4}]$

。

當任意兩個交易

$Tx_i$ 和 $Tx_j$ 有 $\forall\ p\in{P}: T_i[p] < T_j[p]$ ，則表示 $Tx_i$ 發生在 $Tx_j$ 之前

。