Dev Update #2 — 實驗模擬結果

透過本次近況更新您將可以瞭解 DEXON 如何運作及其潛力

DEXON 中文

Published in

DEXONZH

6 min readAug 24, 2018

這幾個月來，我們一直專注在開發 DEXON 的程式架構。本次的近況更新將著重於 DEXON 共識算法第一次實驗模擬結果。

DEXON 實驗模擬結果

實驗環境參數

我們使用了 Intel 第七代 Core-i7 2.9GHz 處理器以及 16GB 2133 MHz DDR3 RAM ，以 Go 編程語言來模擬 DEXON 共識算法的表現。

提醒您，若您尚未對 DEXON 共識算法有足夠瞭解，可能會看不懂以下實驗結果，建議您先詳讀 DEXON 共識算法文件。

惡意節點數量與交易確認延遲實驗

以下的圖表顯示了在不同出塊時間下惡意節點的影響力。當 κ = 0 時，即便只有一個惡意節點（Byzantine node）也會影響確認交易的速度，因為絕大多數的區塊產出都是 normal delivery ，當 κ = 1 或 2 時，交易確認延遲幾乎沒有改變，代表惡意節點無法影響其他節點確認交易的速度。

出塊時間 0.2 秒的狀況：

不同惡意節點數量、不同 κ 值的交易確認延遲表現。（節點數量 = 19 ，出塊時間 0.2 秒，網路傳輸延遲 0.25 秒）

出塊時間 0.5 秒的狀況：

不同惡意節點數量、不同 κ 值的交易確認延遲表現。（節點數量 = 19 ，出塊時間 0.5 秒，網路傳輸延遲 0.25 秒）

網路傳輸延遲與出塊時間實驗

根據 DEXON 的共識算法結構，我們可以推估交易確認延遲公式如下：

交易確認延遲 = 2*網路傳輸延遲（來回）+ 出塊時間 + 運行全局排序算法時間。其中運行全局排序算法所需時間相當的低，當節點數量 ≤ 30 時，小於 0.1 秒。

從上述公式可得出，在運行全局排序算法時間可忽略不計的狀況下，交易確認延遲主要會受網路傳輸速度及出塊時間影響，我們模擬了不同網路傳輸速度與出塊時間的延遲表現，實驗結果證實了我們的想法，如下面 2 圖所示。

出塊時間 0.5 秒的狀況：

在有惡意節點的狀況下，不同網路傳輸延遲、不同 κ 值的交易確認延遲表現。（節點數量 = 19，出塊時間為 0.5 秒）

網路傳輸延遲 0.25 秒的狀況：

在有惡意節點的狀況下，不同出塊時間、不同 κ 值的交易確認延遲表現。（節點數量 = 19，網路傳輸延遲為 0.25 秒）

出塊吞吐量與節點數量實驗

出塊吞吐量與系統中的節點數量呈線性成長，因為全局排序算法不會堵塞（non-blocking），所有節點都可以並行運算。模擬結果驗證了我們的假設是正確的，如下圖所示：

網路傳輸延遲實驗

在沒有惡意節點的狀況下，不同節點數量、不同 κ 值的交易確認延遲表現。（出塊時間 0.5 秒，網路傳輸延遲 0.25 秒）

BPS （Block Per Second）實驗

在沒有惡意節點的狀況下，不同節點數量、不同 κ 值的 BPS 表現。（出塊時間 0.5 秒，網路傳輸延遲 0.25 秒）

惡意節點 Fail-stop 實驗

我們實驗了在有惡意節點 Fail-stop 的狀況下， NACK 機制的表現。實驗環境：節點數量 = 19、出塊時間 0.5 秒、網路傳輸延遲 0.25 秒。我們設置了 6 個惡意節點在第 15 秒時當機並停止運作。

實驗結果證明，當機節點確實對網路會造成影響。圖中的 X 軸是時間，Y 軸是被每個節點確認過的平均區塊數量，也就是所有經過全局排序算法運算後的區塊數量，除以正常節點的數量。

我們在所有 19 個節點中，設置了 6 個惡意節點，所有的惡意節點都在第 15 秒當機。平均來說，系統中的節點每秒可以產出 2 個區塊。當惡意節點當機時，所有的區塊不是經由 NACK 機制產出，就是在 early delivery 的狀況下被產出。在 κ = 0 的狀況下， early delivery 的比率幾乎是 0，因此這個狀況之下只會經由 NACK 機制產出區塊。另一方面，在 κ = 1 或 2 的狀況下，early delivery 的比率相當高，產出區塊的效率並未受到太大影響。