國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
第五章 實驗結果
本章節包含對我們實作 BFT 共識版本的 geth 進⾏的初步測試。實驗測試皆是在
Amazon EC2 t2.medium實體上進⾏。t2.medium 的硬體規格為 2 個虛擬 CPU 與 4GB 的 記憶體。交易型態則是基本的以太坊轉帳交易。我們以交易的延遲性(latency)與交易的 吞吐量(throughput)來衡量共識的效率。這些指標值的計算要透過⼀些程式來完成。另
⼀⽅⾯我們量測共識演算的延展性 (scalability) 以瞭解當參與共識的節點數量變多的時 候，我們的共識機制的效能會受到怎樣的影響。
5.1 環境建置
⼀開始先將所有節點互相連接，即每個節點都會互相知道彼此的位置。在佈署所有節 點之後，我們先建⽴交易並將交易預先載⼊⾄各個節點，讓產⽣區塊的時候能夠包含 最⼤數⽬的交易。我們改變原本 Go-Ethereum 底下蒐集交易的 Txpool，使其可以蒐集 更多交易（原本交易最多為 4096，改成 12000）。
5.2 吞吐量與共識時間
對於測試基本的交易吞吐量與區塊共識時間的測試，我們預先載⼊ 12000 筆交易，並 且每個區塊都包含⼤約 1000 筆交易，總共進⾏ 12 個⾼度。選擇每個區塊 1000 筆交易 的原因在於 geth 本⾝在建⽴與提交區塊皆需要時間進⾏，在這限制之下我們測試結果
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
圖 5.1、圖 5.2 為此實驗結果。從圖四可以看出在我們的共識演算法之下吞吐量皆 會⾼於原本⼯作量證明機制的吞吐量。在 16 個節點以下的吞吐量都有每秒 600 個交易 以上的速度，但是到了 32 個節點的時候卻降低到每秒 400 個交易以下。
Figure 5.1 節點數 vs 吞吐量
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
Figure 5.2 節點數 vs 延遲時間
5.3 拜占庭容錯測試
除了進⾏效能測試，我們也針對拜占庭錯誤節點進⾏測試，檢視我們系統對於可能的 拜占庭攻擊有的容錯能⼒。
⾸先，我們參考 Tendermint 的測試，設計了幾種可能的攻擊模式：
l Proposer提出不同的候選區塊：當輪到拜占庭攻擊的節點當 Proposer 時，該節點 會提出兩個不同的候選區塊，並且將區塊分別傳給不同節點，意圖將兩個網路分 開。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
l 不投出 Nil 的票：該節點不會投出任何 Nil 區塊。當有 Proposer 因為網路延遲⽽在 限制時間之後，都還沒提出區塊時，節點可投出 Nil 可以讓共識持續進⾏，保護 網路的持續性。當節點不投出 Nil 可能會阻礙共識進⾏，甚⾄引響活性。
l 贊成每個收到的候選區塊：此種模式下的節點會贊成每個收到的候選區塊，並在 收到候選區塊的當下就廣播該區塊的 Prevote 與 Precommit 給其他節點。
當⼀個節點有上⾯三種攻擊模式之⼀，即是拜占庭攻擊節點。此種節點如果超過 整個網路的 1/3 以上即會造成整個網路癱瘓，無法達成共識。對於此種攻擊測試，我 們在整個網路有 4 個節點，並且讓其中⼀個節點同時有上⾯三種攻擊⽅式，成為拜占 庭攻擊節點。同樣我們預先載⼊ 20000 筆交易，並且每個區塊都包含⼤約 1000 筆交 易，總共進⾏ 20 個⾼度。圖 Figure 5.3 是此實驗的結果，橫軸代表區塊⾼度，縱軸代 表該區塊共識的時間。從圖中可以看出，約每 4 個區塊會有⼀個區塊共識需要⽐較⾧
的時間，⽽造成那些區塊會需要較多時間的原因即是拜占庭節點為 Proposer 時，該節 點送出了兩個不同的區塊試圖分離網路，所以其他節點會需要更多的時間或是回合數 去完成共識。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
Figure 5.3 在有拜占庭攻擊節點的情況下，區塊共識所需時間
雖然會讓整體的網路延遲時間變⾧，不過整個網路還是能夠完成共識，表⽰我們 的系統在攻擊節點不超過 1/3 的情況下，還是能夠保有持續性。從交易的吞吐量來 看，當整個網路有 4 個節點，正常狀態下，每個區塊⼤約需要 1 秒的時間，每秒交易 量約為 1000 個交易，⽽在拜占庭共識的情況下，每個區塊需要的共識時間⼤約為 1.9 秒，每秒的交易量約為 500 個交易。整體⽽⾔，拜占庭攻擊還是導致共識時間的延
⾧，讓交易吞吐量減少。
‧
PBFT、Hydrachain 等，並改進後將共識演算法實作於以太坊的共識模組之上，讓以太 坊可以切換不同的共識機制，部署私有鏈或是聯盟鏈。另外我們也對我們實作的系統 與共識的名單路在區塊的 extraData 部分，讓名單可以直接儲存在區塊鏈中。Clique 另 外利⽤原本區塊 Header 中沒有使⽤到的欄位，讓原本的驗證⼈員以類似投票的⽅式，
進⾏名單的新增或修改，讓名單不會只限於⼀開始設定的⼈員。此⽅法另⼀個好處 是，因為名單的內容與修改都是透過區塊來進⾏，所以所有的步驟與時間皆會伴隨著 區塊記錄下來，在未來如果發⽣爭議還可以透過區塊上的資訊進⾏追朔動作。