實驗內容

該節開始會詳細敘述本論文的實驗目的、方法，以及實驗結果評估的定義。

第一段 實驗目的

本論文的實驗目的就是打算替換掉 Libra 原本用來儲存整體帳本資訊的 Jellyfish Merkle tree 改成本實驗室所研發的 tp-Merkle tree，因此本論文會模擬一 個Libra 的程式環境，並且為了使的比較方式能夠公平，所以本論文參照 Libra 的 GitHub 中的程式碼[9]自行實作了一個 Java 版本的 Jellyfish Merkle tree。

第二段 實驗結果評估方法定義

這個段落我們將要介紹如何評估實驗結果，最直接的方式就是紀錄整體操作 時間並作比較，下圖是Libra 執行一個的架構圖，我們定義了幾個變數。

圖 15 Libra 架構圖與本論文定義之相關變數

1. n：交易數目

2. α：提交交易的傳輸時間 3. ß：領導節點廣播交易時間 4. c：運算 Merkle tree 時間 5. γ：共識投票時間

24

因此我們可以估算執行時間(Execution time)為:

Execution time =𝛼 + 𝛽 + 𝑐 + 𝛾 𝑛

則內文經常提到的每秒交易量(TPS)則為其倒數：

𝑇𝑃𝑆 = 1

Execution time= 1

(𝛼 + 𝛽 + 𝑐 + 𝛾𝑛 )= ( 𝑛

𝛼 + 𝛽 + 𝑐 + 𝛾)

我們的目的是為了比較TPS，TPS 越高就表示能在同一時間中處理更多的交 易量。TPS 為執行時間之倒數，因此我們希望能有較少的執行時間，在 n 不變的 情況下，基本上只要我們能夠降低α、ß、c 和 γ，我們就能取得少的執行時間。

本論文為了能簡單明瞭了分析，本論文使用單個驗證節點的 Libra 架構，減 少不穩定而造成的時間上的差異以及共識的時間，並且將客戶端與驗證節點放置 在同一台電腦，因此最終我們只會比較”c”的時間，也就是單純比較交易在存入 Merkle tree 後產生根雜湊的執行效率上之差異。

25

第三段 實驗步驟

圖 16 實驗架構圖

上圖是將驗證節點中執行的部分細分出來，而整個實驗步驟詳細可以分為8 個

步驟：

1. 生成 K 個帳戶地址(account)，並預先存入 N 個 Libra coin

2. 任意選擇兩個帳戶地址(account)Ax和Ay，並創建一筆交易T，內容為轉帳，

將Ax轉Ay 1 個 Libra coin，並將交易送給驗證節點的准入控制器(Admission control)

3. 准入控制器(Admission control)確認交易 T 的合法性，確認合法才會放入記憶 體暫存池(Mempool)

4. 驗證節點從記憶體暫存池(Mempool)取出 N 筆交易內容(T1~TN)

5. 執行所有交易並將結果存入 Jellyfish Merkle tree/ tp-Merkle tree 中，並計算根 雜湊(Root hash)

6. 將結果存入資料庫(DB, Database)中 7. 完成轉帳，公布交易結果

26

在第2~3 步驟會重複 N 次，用以累積一定的交易數量，用以做批次處理。其 中架構中的部件所代表之意義：

1. 帳戶生產器(Generate account)：透過一個函式自動產生大量合法不重複的帳戶 地址以及其帳戶資訊內容。

2. 准入控制器(Admission control)：在交易進入驗證節點的交易暫存池之前，會先 經過准入控制器，准入控制器會從帳本資料庫取出上個狀態的帳戶資料來判 Jellyfish Merkle tree 和 tp-Merkle tree 兩種，這也是本論文主要比較的地方。

5. 帳本資料庫(DB)：實際儲存交易帳本的位置，不僅儲存樹的節點，也有儲存帳