tp-Merkle tree 提高公有區塊鏈交易速度之研究

全文

(1)國立臺灣師範大學理學院資訊工程學系碩士論文 Department of Computer Science and Information Engineering College of Science. National Taiwan Normal University Master’s Thesis. tp-Merkle tree 提高公有區塊鏈交易速度之研究 Using tp-Merkle tree to Increase TPS of Public Blockchain. 黃英睿 Huang, Ying-Jui. 指導教授：黃冠寰博士. 中華民國 109 年 8 月 August 2020.

(2) 謝辭流光易逝、歲月如流，兩年的在師範大學的研究所生活就這樣過去了，在完成本篇論文後，有種柳暗花明、感慨良多，首先感謝我的指導教授黃冠寰博士在我挑選論文題目時，給我很多選項和建議，以及教授對我們的論文和平時的報告都非常的嚴格，也就是因為這樣，才讓我們在這兩年間有非常不錯的成長。還記得教授時常引用愛因斯坦的名言：「如果您不能簡單地解釋它，則說明你不夠了解。」，這句話也在之後常常被我記在腦中，時常提醒自己。另外還要感謝實驗室的學長培均，在我剛入實驗室告訴我許多選課上的方向以及要去哪裡看論文等等。還要感謝我實驗室的同學東霖、仲嘉、政佑、宏文、亦祥、麒翔和毅軒，不管是在各自看的論文上的互相分享，或是課堂內容上的切磋討論，都使得我們能夠齊心協力的度過這兩年。最後要感謝的是我的父母，因為他們這 20 多年不辭辛勞的栽培我，讓我衣食無慮，且能夠供給我一路讀到研究所，才能有今日擁有如此成就的我。最後再對許多一路上幫助過我、教育過我的人，雖然無法在此一一提及，但我依然表達由衷的感謝。黃英睿. 誌於. 國立臺灣師範大學資訊工程所民國. i. 109 年 7 月.

(3) 摘要 tp-Merkle tree 提高公有區塊鏈交易速度之研究黃英睿自從 2008 年，中本聰首次提出區塊鏈(Blockchain)概念以及世界知名的比特幣 (Bitcoin) 以來，世界上已經提出了許多種基於區塊鏈的加密貨幣 (Crypto currency) 。現在主流的加密貨幣如以太坊(Ethereum) 或萊特幣(Litecoin) 等，他們每秒的交易時間都受到共識決的限制，使得他們的 TPS 都不太高，萊特幣約 50 TPS，以太坊約 20 TPS，比特幣更是只有不到 10 TPS，而現在主流的支付系統 VISA 則是達到每秒 6000 筆交易，所以目前主要的加密貨幣都是被當作股票投資，比較沒有辦法廣泛應用在生活中。近期(2019/06)，Facebook 提出一個全新的加密貨幣 – Libra[1]，和以太坊一樣有拜占庭協議的容錯機制和使用默克爾樹(Merkle tree)來保證整體交易的完整性，且他們宣稱他們的 TPS 可以達到每秒 1000 筆交易，可以用在小額支付的場景，但這點被許多人所質疑。因此在本論文中，我們將 Libra 所使用的 Merkle tree- Jellyfish Merkle tree 來和我們實驗室中具有快速索引定位功能的 tp-Merkle tree 來做實驗進行比較。. 關鍵字：區塊鏈、虛擬貨幣、Libra. ii.

(4) 目次謝辭 .............................................................................................................................. i 摘要 ............................................................................................................................. ii 目次 ............................................................................................................................ iii 表次 .............................................................................................................................. v 圖次 ............................................................................................................................. vi 第一章緒論 ................................................................................................................1 第一節數位貨幣(Digital Currency) ................................................................................. 1 第二節 Libra ...................................................................................................................... 2 第三節 Libra 所面臨的問題 ............................................................................................. 3 第四節章節介紹 ............................................................................................................... 4. 第二章相關回顧 .........................................................................................................5 第一節雜湊函式 (Hash function) .................................................................................... 5 第二節默克爾樹 (Merkle tree) ........................................................................................ 5 第三節區塊鏈 (Blockchain) ............................................................................................ 7 第四節 Libra Protocol 和 Libra Blockchain 簡介 .......................................................... 8. 第三章實驗架構 ....................................................................................................... 12 第一節 Jellyfish Merkle Tree .......................................................................................... 12 第一段資料結構詳述 ............................................................................................................... 12 第二段操作流程 ....................................................................................................................... 13. iii.

(5) 第二節 tp-Merkle tree ..................................................................................................... 18 第一段資料結構詳述 ............................................................................................................... 18 第二段操作流程 ....................................................................................................................... 19 第三段較 Jellyfish Merkle tree 優勢之處 ................................................................................. 20 第四段批次操作 ....................................................................................................................... 21. 第三節實驗內容 ............................................................................................................. 23 第一段實驗目的 ....................................................................................................................... 23 第二段實驗結果評估方法定義 ................................................................................................ 23 第三段實驗步驟 ....................................................................................................................... 25. 第四節使用 tp-Merkle tree 可能遇到的問題................................................................. 26 第一段碰撞攻擊 ....................................................................................................................... 26 第二段解決方式 ....................................................................................................................... 28. 第四章實驗結果 ....................................................................................................... 29 第一節 Jellyfish Merkle tree 實驗結果 .......................................................................... 30 第二節 tp-Merkle tree 實驗結果.................................................................................... 32 第一段批次測試 ....................................................................................................................... 32 第二段不同樹高分析 ............................................................................................................... 33. 第三節 Jellyfish Merkle tree 與 tp-Merkle tree 結果比較 ........................................... 36. 第五章結論 .............................................................................................................. 38 參考文獻 .................................................................................................................... 39. iv.

(6) 表次表 1 在 21 層樹高 100 萬筆帳戶的狀態下模擬碰撞攻擊時被攻擊區和其他區域的修改時間差異 .. 27 表 2 JELLYFISH MERKLE TREE 創建 1 萬~1000 萬筆資料時間、耗費記憶體與硬碟儲存空間............ 30 表 3 JELLYFISH MERKLE TREE 創建 1 萬~1000 萬筆平均深度、最小深度與最大深度 ....................... 30 表 4 修改 1 萬~1000 萬筆資料時間以及每秒平均修改次數 ............................................................. 31 表 5 TP-MERKLE TREE 樹高 17~25 非批次修改時間與取雜湊次數 .................................................... 32 表 6 TP-MERKLE TREE 樹高 17~25 批次修改時間與取雜湊次數........................................................ 32 表 7 TP-MERKLE TREE 13~25 層樹高創建 1000 萬筆資料時間、耗費記憶體與硬碟儲存空間........... 33 表 8 TP-MERKLE TREE 13~25 層樹高創建 1000 萬筆平均碰撞、最小碰撞和最大碰撞 ...................... 34 表 9 TP-MERKLE TREE 13~25 層樹高修改 1000 萬筆資料時間以及每秒平均修改次數 ...................... 35 表 10 兩種樹創建 100 萬的執行時間、耗費記憶體及耗費儲存空間之比較 .................................... 36 表 11 兩種樹創建 1000 萬的執行時間、耗費記憶體及耗費儲存空間之比較 .................................. 37 表 12 兩種樹在已經存在 100 萬執行 1000 筆帳戶餘額修改時間及每秒平均修改次數 ................... 37 表 13 兩種樹在已經存在 1000 萬執行 1000 筆帳戶餘額修改時間及每秒平均修改次數 ................. 37. v.

(7) 圖次圖 1 默克爾樹(Merkle tree)................................................................................................................... 6 圖 2 默克爾樹僅使用部分節點求出根雜湊 ......................................................................................... 6 圖 3 Libra Protocol 架構 ...................................................................................................................... 9 圖 4 稀疏默克爾樹計算雜湊範例 ...................................................................................................... 12 圖 5 Jellyfish Merkle tree 節點類型 ................................................................................................... 13 圖 6 Jellyfish Merkle tree 根節點 ....................................................................................................... 14 圖 7 Jellyfish Merkle tree 根節點下附帶一個葉子節點 ..................................................................... 14 圖 8 Jellyfish Merkle tree 根節點下附帶一個內部節點 ...................................................................... 15 圖 9 Jellyfish Merkle tree 根節點下附帶一個內部節點與一個葉子節點........................................... 16 圖 10 Jellyfish Merkle tree 根節點下附帶一個內部節點與一個葉子節點......................................... 16 圖 11 Jellyfish Merkle tree 內部節點展計算雜湊值範例 1................................................................. 17 圖 12 Jellyfish Merkle tree 內部節點展計算雜湊值範例 2 ................................................................ 17 圖 13 tp-Merkle tree 架構圖 ............................................................................................................... 18 圖 14 tp-Merkle tree 批次處理範例.................................................................................................... 22 圖 15 Libra 架構圖與本論文定義之相關變數 .................................................................................... 23 圖 16 實驗架構圖 .............................................................................................................................. 25 圖 17 tp-Merkle tree 樹高分析 ........................................................................................................... 36. vi.

(8) 第一章緒論第一節數位貨幣(Digital Currency) 數位貨幣(Digital Currency) 是一種以數位記帳的方式來交易的貨幣系統，所有的帳本及交易資訊都儲存在計算機的數據庫中，其中一方可以透過數位貨幣來購買或交換另一方的產品或服務，交易過程通常不用經過人手去點算現金，主要通過計算機系統去完成。在法律上通常不被視為法定貨幣，而只會被視為財產，他在部分情況下他們會具有與法定貨幣類似的性質，可被允許即時的金融交易支付。數位貨幣的常見存在的形式包括虛擬貨幣、加密貨幣、中央銀行數位貨幣、電子貨幣、網路貨幣等，這些類型的貨幣可被用於購買商品或服務，但也有部分只僅限於某些社群，如線上遊戲的虛擬貨幣只能被用於該款線上遊戲。數位貨幣的系統根據儲存方式的不同主要分為兩種：集中式系統和分散式系統，集中式系統如台灣的悠遊卡、I Cash 或是一卡通等等，都是由一個集中式的系統來發行、管理和流通等等，集中式的數位貨幣類似於一般法定貨幣，基於對於中央式機構的信任，一旦中央式的機構故障或是被斷電可能不能再用這個系統，而相反的使用分散式系統的數位貨幣就不會有這個問題，因為每個人的帳本被分散的紀錄，就算其中一個點故障，也可以再去訪問其他的點，但他會出現另一個問題，也就是因為帳本被分散式的紀錄在每個人的身上，所以每次的交易都必須. 1.

(9) 經過一段時間的共識和同步，所以整體交易的速度就因此被拉低，而中央式系統就沒有這個問題，帳本只需紀錄在中央式資料庫即可。. 第二節 Libra Libra 是 Facebook 在 2019 年 6 月所推出的一種數位貨幣，其目標是建立一個簡單的數位貨幣和金融系統，為全球二十億人提供金融服務。其中最主要的目的是形成一個低手續費的全球轉帳系統。為了保持 Libra 價值的穩定性，在其背後有真實世界的資產(央行發行的貨幣與政府債券)當儲備資金，分別以美元(USD)、歐元(EUR)、日圓(JPY)等，價值相對穩定。在初期只有只有 Libra 的會員才能成為節點，且驗證資格非常的困難，必須是該行業的前 100 大企業才可加入，且每個會員在加入時就必須支付 US$10 萬元，成為 Libra 的儲備資金。 Facebook 表示互聯網與智慧型手機的發明令全世界數十億人都可以快速的獲得資訊以及各式各樣低成本的服務，在世界幾乎每一處都能使用互聯網，這種方便性使得可以讓更多人進入金融系統。儘管科技如此進展，但全球還是有近 17 億的成年人是未接觸到金融系統的，無法享受到傳統銀行提供的金融服務系統，在其中是有數 10 億人擁有手機，其中近 5 億人是有上網能力的。因此 Libra 協會得最終目的就是希望全世界的人都能夠像是使用簡訊一樣方便安全的方式就可以進行全球低手續費的轉帳系統，使得那些無法開立銀行帳戶的人，也能夠享受現今方便快捷的金融服務。Libra 目前只開放 100 會員成為節點，但 Libra 協會表示，在未來當技術更加成熟且穩定時將會將現在的許可制 2.

(10) 網路轉向成非許可制網路，能夠達到完全去中心化的理念。. 第三節 Libra 所面臨的問題 Libra 自從白皮書發布(2019 年 6 月)以來，一直受到各國政府以及各大銀行所抵制，使得他在各國的發展受到嚴重的阻撓。主要的原因各國政府認為 Libra 屬於一種去中心化貨幣，會造成政府對資本流動的監理產生困難，在其背後可能會有洗錢、非法交易、逃漏稅等風險問題。但 Libra 也不是第一個提出加密貨幣的協會，為什麼各國政府會對 Libra 產生這麼大的畏懼呢？主要是因為 Libra 背後最主要要的開發商是 Facebook，當初 Libra 推出的最主要目標是就是為了服務 Facebook 的這些使用者，根據 Facebook 的數據[2]指出，截至 2020 年 3 月 31 日為止，Facebook 的每月活躍用戶為 26 億人，是中國人口 13 億人的足足兩倍，如果 Facebook 的這些用戶都使用 Libra 的話，Libra 就可能超越美金、歐元和人民幣成為世界上第一大流通的貨幣，因此各國政府與銀行機構都認為在沒有解決的監管問題前就上市，會衝擊現有的金融體系。不過去中心化貨幣本身就是為了擺脫傳統中心化貨幣的監管才產生，所以本論文不對此部分多做分析。處此之外， Libra 還有另外一個明顯的問題 TPS(Transactions Per Second, 每秒交易量)不足的問題，和其他支付系統來比較， 2019 年 Q4 的財報[10]顯示國際知名信用卡公司 Visa 的 TPS 為 6000，2019 年騰訊的財務報告[11]中顯示微信 TPS 甚至破萬，而 Libra 在白皮書上宣稱的 TPS 僅 3.

(11) 為 1000，明顯與上述兩個例子不同。且目前的 Libra 測試鏈[3]上，目前的平均 TPS 還不超過 100，亦有其他論文 [4]做了 Libra 的分析，使用單個節點並使用伺服器高規格等級的去做測試才能測試出 1000 左右的 TPS。Libra 將來在若欲正式發行，除了要解決各國監管問題外， TPS 的問題也是需要解決的項目。因此本論文將使用本實驗所研發的一種 Merkle tree 去嘗試替換 Libra 所使用的 Merkle tree，以試圖改善 Libra 的 TPS 問題。. 第四節章節介紹論文開頭首先闡述數位貨幣以及最近 Facebook 所提出的 Libra，並提出 Libra 推出所發生的問題以及本論文打算用來解決的方法。第二章提到本論文所應要到之相關技術，雜湊函式、默克爾樹等等。第三章開始會說明 Libra 所用到的 Jellyfish Merkle tree 和我們實驗室的 tp-Merkle tree，並詳加說明如何進行實驗流程。第四章將前一章節所提到的實驗撰寫程式進行模擬，並列出實驗結果。第五章將第四章做出來的實驗結果的比較拿出來作結論與分析。. 4.

(12) 第二章相關回顧第一節雜湊函式 (Hash function) 雜湊函式 (Hash function)[5]是可用於將任意大小的值去映射到固定大小的值的函式。雜湊函式返回的值稱為雜湊值 (Hash value)或摘要 (Digests)。這些值用於索引稱為雜湊表的固定大小的表。使用雜湊函式索引雜湊表的過程稱為取雜湊(Hashing)。雜湊有一個特性，若兩雜湊值不同則兩雜湊輸入的值必定不同，就算只是一個 bit 的更動，也會產生出兩個截然不同的結果。但若發現兩個相同的雜湊值，他們的雜湊輸入不一定相同，因為有可能發生了碰撞，但發生碰撞的機率相當的低，幾乎是微乎其微。而且雜湊函式每次的計算時間複雜度基本上為常數時間，因此在區塊鏈中將會有相當多的地方會應用到雜湊函式，用來快速的證明資料的完整性。. 第二節默克爾樹 (Merkle tree) 在密碼學和計算機科學中，默克爾樹(Merkle tree)[6]是一個樹(Tree)的資料結構，這棵樹的每個葉子節點(Leaf node)都是由一個雜湊值所紀錄，而每一個非葉子節點則都是由他們的子節點串聯(Concat)後，在對該值進行雜湊函式所產生。. 5.

(13) 圖 1 默克爾樹(Merkle tree). 雜湊樹的頂部或根部(Root)稱作根雜湊(Root hash)，通常會使用該值來代表整棵默克爾樹的完整性，只要在樹中的任何ㄧ個節點發生改變，那麼根雜湊也會發生改變。. 圖 2 默克爾樹僅使用部分節點求出根雜湊 6.

(14) 且默克爾樹有一個特性給使沒有完整的整棵樹，也能求得根雜湊(Root hash)。例如上圖中，如果樹中只有 Hash b1 和 Hash a，只要能給出正確的 T4 還是能遞迴的算出最後的根雜湊。因為這個特性所以可以只要求一小部分的值(Hash b1 和 Hash a)，就可以證明 T4 是被包含在這棵默克爾樹中的。. 第三節區塊鏈 (Blockchain) 區塊鏈(Blockchain)是一種密碼學技術，是藉由透過串接前一個文字區塊的內容來保護內容的不可竄改性。每一個區塊都包含了前一個區塊內容的雜湊值，一個一個的串起因此得名。分散式帳本(Distributed ledger)是一種多節點的所組成的網路進行電子數據複製、共享並同步的一個技術，其最大的特色是中間並沒有任何的中央管理節點或是集中的數據儲存中心。每個節點的手上都會有一份數據，每當一個帳本出現更新時，每個節點都需要進行共識投票來決定誰的帳本是正確的，若達成共識則所有的節點都對該帳本進行更新。目前區塊鏈透過分散式帳本技術最主流的應用就是加密貨幣，如比特幣 (Bitcoin)、以太坊(Ethereum)和萊特幣(Litecoin)等等。以比特幣的區塊鏈分散式帳本為例，每個區塊都是由該次階段所打包的交易、目前的時間戳記 (Timestamp)、上一個區塊的雜湊以及一個隨機數所組成，區塊鏈中的礦工(某個為大家打包內容的節點)通過工作量證明去決定發塊的節點，以保持整格區塊鏈的安全性，因為負 7.

(15) 責發塊的礦工會在發塊後獲得獎勵，而總比特幣的總數是有限的，所以工作量證明的難度回隨著時間進行挑整而越來越難，因次比特幣的交易速度就會越來越慢。區塊鏈主要分為三種，分別是公有區塊鏈、聯盟區塊鏈和私有區塊鏈：公有區塊鏈，指所有人都可參與區塊鏈成為一個節點，所以公有區塊鏈是一. 個非常去中心化的，但也因為大家都是節點造成節點過多，使得整體區塊鏈的共識時間被拉長，而導致整體區塊鏈的每秒交易數(TPS)無法提高，經典的公有區塊鏈如比特幣和以太坊等。聯盟區塊鏈或私有區塊鏈則不是所有人都可以成為節點的，通常只有少數的. 成員可以作為節點，私有區塊鏈甚至可能只有一個節點，因此中心化程度為弱中心化或強中心化，但也相對的節點少，使得共識的時間不需要這麼久，所以聯盟區塊鏈或私有區塊鏈的每秒交易數通常比公有區塊鏈高出許多。本論文提到的 Libra 就是目前屬於聯盟區塊鏈的一種，未來打算朝著公有區塊鏈邁進。. 第四節 Libra Protocol 和 Libra Blockchain 簡介 Libra Blockchain 是分散式帳本結構，由 Libra Protocol 中的一個驗證節點 (Validators) 所建立，在 Libra 建立初期的這些驗證節點將會由地理上的分佈和多樣性的創始會員組成，隨著時間的推移會慢慢將會員資格轉向開放制。 Libra Protocol 是在 Libra 之中用於維護 Libra Blockchain，使不同的驗證節點可以共同維護這個加密的資料庫帳本，資料庫中存放很多的”資源(此處亦指 8.

(16) Libra 的貨幣，Libra 的貨幣稱為 Libra 其單位為 LIB)”，這些資源由擁有公私鑰對的客戶端(Client) 所擁有，並使用其客戶端的金鑰對這些資源進行加密，並可以對帳戶中的資源進行操作。 Libra Protocol 主要由兩個實體部分組成，分別是 1. 維護資料庫的驗證節點(Validators) 2. 客戶端(Client). 圖 3 Libra Protocol 架構. 由這兩個主要的實體部分又可以如上圖所示簡單分成五個步驟： 1. 驗證節點維護數據庫並處理客戶端提交的交易以打包進資料庫中。 2. 驗證節點輪流推動接受交易的過程。當其中一個被推選出來的驗證節點充當領導節點(leader)時，它會將客戶端提交給他們的交易交給其他驗證節點(other validator)。 3. 所有驗證節點都執行(execution)交易，並形成包含經過身份驗證的新帳本歷史記錄的數據結構。 4. 每個驗證節點將執行完的交易後，就會對領導節點所執行完成的交易進行投票驗證，已確認交易執行正確。 5. 領導節點會將完成的交易 T 的完整狀態做簽名放置在資料庫中，並附上證據(proof)，以讓客戶端可以對該筆交易進行驗證。. 9.

(17) Libra Protocol 進行投票驗證是使用類似拜占庭協議的共識決議，只要有 2f+1 個驗證節點對該領導節點進行驗證投票，就可以確認該次交易的合法性，其中 f 只是所有驗證節點中壞掉或是惡意的驗證節點。只要惡意的驗證節點不超過所有的驗證節點的一半都可以保證有正確的交易結果[7]。客戶端可經過向驗證節點發出查詢請求，以取得最新的版本的資料庫狀態，並且也可以返回最新的經過驗證節點簽名並附上證據的交易結果，供客戶端對該筆交易做驗證的動作。 Libra Blockchain 的所有資料都是儲存在具有版本的加密的資料庫帳本中，版本號是一個無符號的 64 位元整數(264 = 1.844e+19)，對應系統執行的交易數。這個數量至少可以供給 10 億(1.0e+10)個用戶每個用戶都個執行約 10 億次的交易。具有版本的加密的資料庫帳本的允許驗證最新版本的帳本狀態，亦可以去返回過去特定版本的帳本歷史供給客戶端查詢。每個帳戶地址(Account address)是 256 位元，相當於可以產生最 2256 個不重複的帳戶地址，為了要創立新的帳戶，必須使用非對稱式加密產生新的公私鑰對(pk, sk)，並使用公鑰 pk 取雜湊值作為帳戶的地址 (Account a = hash(pk)) 每個帳戶只會在當有 Libra 發送到該個帳戶中才會被加入加密的資料庫帳本中，表示該帳戶在 Libra Protocol 中被建立，當該個帳戶被建立後，就可以透過私鑰 sk 簽署要從該個帳戶所發送的交易。 Libra Protocol 不會將帳戶與真實身份相關聯。客戶端可以產生多組密鑰對來 10.

(18) 創建多個不同的帳戶(account)。由相同的客戶端所控制的帳戶間是沒有固有的相關聯。該方案遵循比特幣和以太坊的例子，因為它為用戶提供了假名。客戶端在 Libra 上執行交易後，會經由驗證節點將其存入加密的資料庫帳本中，在這個資料庫帳本中包還了一個 Ledger State 的一個結構，該結構就是代表整個 Libra Protocol 中所有帳戶的狀態，Ledger State 是一個默克爾樹(Merkle Tree)，他將客戶端所建立的長度有 256 個位元帳戶地址當作鍵值映射到這顆默克爾樹上，所以會創造出一顆葉子節點就具有 2256 的一棵默克爾樹。大小為 2256 的一棵默克爾樹是一個非常難以處理的大小，所以 Libra Protocol 透過一種名叫 Jellyfish Merkle Tree 的一種稀疏默克爾樹來應用，該個樹的詳細內容與架構將會在本論文的下個章節做介紹。. 11.

(19) 第三章實驗架構第一節 Jellyfish Merkle Tree 第一段資料結構詳述 Jellyfish Merkle tree 用於在 Libra 中儲存帳本狀態，由 Libra 團隊所研發的的一種稀疏默克爾樹，理論上最多可以有 2256 個葉子節點。 Jellyfish Merkle tree 是一種改良過的稀疏默克爾樹(Sparse Merkle tree)，其特點在於任何沒有值的葉子節點在根節點到該葉子節點之間的節點都將被省略，以節省儲存空間。. 圖 4 稀疏默克爾樹計算雜湊範例. 上圖說明此改良過的稀疏默克樹，該子樹僅 A、B、C 三個位置有值，那麼其他不存在值的地方都會被省略。此方法不僅減少儲存空間，間接地也減少取雜湊的次數，上圖狀況的 Root hash = Hash(a, Hash(b, c))，僅需取 2 次雜湊值，若是原本左邊的方式需要取 15 次雜湊值。. 12.

(20) Jellyfish Merkle tree 有兩種節點，分別是內部節點(Internal node)和葉子節點 (Leaf node)，內部節點最可以包含 16 個子樹，葉子節點則是儲存帳戶地址和 hash(blob)，其中 blob 指的是該個帳戶的資訊，如餘額、交易次數等等。. 第二段操作流程本段將說明本論文以程式去實作 Jellyfish Merkle tree 方法，第一先說明如何在程式中實現該架構，接著說主要的操作流程。首先介紹儲存的架構，上段有提到 Jellyfish Merkle tree 主要以兩種節點組成：內部節點與葉子節點，如下圖所示，內部節點會紀錄哪個子節點下有子樹存在，並記錄該子樹的根雜湊，葉子節點則是紀錄帳戶資訊。另外這兩種節點都會儲存現在節點的路徑(Path)，用於當作定位方式。. 圖 5 Jellyfish Merkle tree 節點類型. 這個路徑指的是從最上層的內部節點，也就是根節點(Root node)一直到目前這個節點的路徑，其中根節點的路徑為空(Empty)，也就是根節點中儲存路徑的位置所儲存的會是一個空值，為根節點的特徵。. 接下來說明主要的操作流程，主要有以下幾個：(1)在空樹中創建葉子節點、 (2)探索葉子節點、(3)新創共同節點、(4)更新葉子節點和(5)計算雜湊值，以下將一一介紹。 13.

(21) (1) 在空樹中創建葉子節點所有的操作流程都必須從根節點開始操作，因此不管是什麼操作，首先都確認是否有根節點，若不存在根節點則必須先創建一個根節點，前面提到根節點也是一個內部節點，只是他的路徑欄位將永遠是空的。. 圖 6 Jellyfish Merkle tree 根節點. (2) 探索一個葉子節點接下來根據輸入的帳戶地址來從跟節點開始來探索葉子節點，會從帳戶的第一個字元開始探索，假設今天輸入的帳戶地址是 0xa171355，則第一個被探索的將會是”a”，目前探索到的節點為上圖的 Node 1，”a”的位置是空的，表示該子樹下沒有任何的值，因此必須在該位置上新增一個葉子節點(Leaf node)。. 圖 7 Jellyfish Merkle tree 根節點下附帶一個葉子節點. 14.

(22) 現在已經新增完成了，當我們再一次去探索 0xa171355 這個帳戶地址時，一樣從根節點 Node1 開始，並取從帳戶的第一個字元”a”開始探索，發現 Node1 在”a” 這個位子是有子節點的，就將目前節點位置移到 Node2，發現 Node2 是一個葉子節點，便比較該葉子節點的帳戶地址與目前在探索的帳戶地址是否相同，發現相同，則表示探索到該帳戶所代表的葉子節點。. (3) 新創共同路徑接續前一個段落，若假設今天要探索的帳戶地址不是 0xa171355 而是 0xaf79365，比較完 Node2 的帳戶地址會發現不相同，於是將目前的 Node2 放置到暫存區，並取出兩個帳戶地址共同的前綴路徑，共同的路徑為”a”，於是在前這個位置在新增和共同路徑長度相同的內部節點，共同路徑長度為 1，所以僅需再創造一個新的內部節點，並將其的路徑設置為”a”，如下圖所示。. 圖 8 Jellyfish Merkle tree 根節點下附帶一個內部節點. 將暫存區中的 Node2 取出，再從目前探索到的點再向下探索，目前探索到的路徑是”a”，探索到的節點則是剛剛新增的內部節點 Node3，Node2 的帳戶地址在 15.

(23) 去除共同路徑後的下個字元為”1”，目前 Node3 的”1”這個位置是空的，便直接將 Node2 放置於此，將路徑修改為帳戶地址與共同路徑比對後再多放置一個字元，即將 Node2 的路徑修改為”a1”，結果如下圖。. 圖 9 Jellyfish Merkle tree 根節點下附帶一個內部節點與一個葉子節點. 目前探索的帳戶地址在去除共同路徑後的下個字元為 f，目前 Node3 的”f”這個位置也是空的，於是在該位置上新增一個葉子節點(Leaf node)，將該節點的路徑設定為”af”，結果如下圖。. 圖 10 Jellyfish Merkle tree 根節點下附帶一個內部節點與一個葉子節點 16.

(24) (4) 更新葉子節點更新葉子節點的方式只需先探索到該個葉子節點後，直接修改該葉子節點的 blob 為新的值即可。 (5) 計算雜湊值每個內部節點看似都是一個有 1 層 16 個子節點的節點，但在計算該內部節點的雜湊值時，是將其模擬成有個 4 層的 2 元樹來做計算，這棵 4 層的 2 元樹的根雜湊(Root hash)就是該個內部節點的雜湊值，如下圖所示。. 圖 11 Jellyfish Merkle tree 內部節點展計算雜湊值範例 1. 但他依然保有稀疏默克爾樹的特性，只要該子節點沒有值就會被省略，因此最後在計算這個內部節點(Internal node)的雜湊時，只需計算 hash(4,hash(8,b)). 圖 12 Jellyfish Merkle tree 內部節點展計算雜湊值範例 2. 17.

(25) 第二節 tp-Merkle tree 第一段資料結構詳述 2016 年由黃冠寰博士於 International Conference on Cloud Computing 所發表的論文[8]中提出的架構-定位默克爾樹(Index Merkle tree)，在黃冠寰博士近期將該樹的正式名稱定義為 Transaction Positioned Merkle Tree (tp-Merkle tree)，是一種默克爾樹(Merkle Tree)。. 圖 13 tp-Merkle tree 架構圖. tp-Merkle tree 的架構是一個完滿二元樹，整體結構可以分為根節點(Root node)、內部節點(Internal node)和葉子節點(Leaf node)，如果樹的高度是 H，則整棵樹會有 2H-1 個節點和 2H-1 個葉子節點，以上圖為例，假設樹的高度是 4，則會有 15(24-1)個節點和 8(24-1)個葉子節點，且不管是根節點、內部節點或是葉子節點都是存放一個雜湊值。葉子節點是由 Pair List 中所有的值取雜湊產生，在本論文中 Pair List 是一 18.

(26) 個 Key-value pair，Key 是一個帳戶地址(Account address)，Value 則是該帳戶的帳戶資訊(如餘額，交易次數等等)取 hash 所組合而成。內部節點是由左子節點的雜湊值和右子節點的雜湊值串連起來取雜湊，並設為該內部的雜湊值，重複執行以上結果一直由底部運算到頂部，最後會得到根雜湊(Root Hash)，而這個根雜湊就是用來證明這棵樹完整性的重要證據。 tp-Merkle tree 其最主要的特色是能透過定位函式來快速定位需要修改節點位置，進而大幅提高整體樹的操作速度。. 第二段操作流程 tp-Merkle tree 的動作相對於 Jellyfish Merkle tree 來說相對簡單，因為他是一個完滿二元樹，所以在一開始就必須現創建出樹高大小的二元樹。又因為所有的節點都是預先創好的，因此我可以將這些節點存放在和節點數量相同的陣列中，不像 Jellyfish Merkle tree 是為隨著時間動態新增節點的。 tp-Merkle tree 只有一個動作，就是存放一個值到樹中，我們稱這個動作為”put”，每當有一筆帳戶去做更動或是新增時，會使用一種定位函式(Index Function)去定位到該地址所對應到的葉子節點的位置，Index Function Γ 的函式如下： Γ(𝑎𝑑𝑑𝑟𝑒𝑠𝑠) = 𝑆𝐻𝐴256(𝑎𝑑𝑑𝑟𝑒𝑠𝑠)𝑚𝑜𝑑 2345 本論文為了配合 Libra 的定位方式，將原本的定位函式改為以下這個方程式： Γ(𝑎𝑑𝑑𝑟𝑒𝑠𝑠) = 𝑃𝑟𝑒𝑓𝑖𝑥 _ 𝐻 − 1 _ 𝑏𝑖𝑡(𝑎𝑑𝑑𝑟𝑒𝑠𝑠) 19.

(27) 上述的定位函式表示取該 address 的前 H-1 個 bit 當定位，假設樹高是 4，如果有一個 address 是 0b0100 0000，則透過 Index Function 會求得 0b010(=十進制的 2) 的位置，也就是這筆 address 的資料會被存放在 Leaf Node ID = 2 的位置上。其中 address 指的是帳戶地址，H 指的是樹高。. 第三段較 Jellyfish Merkle tree 優勢之處主要是兩個點比 Jellyfish Merkle tree 優秀： 1. Traversal 及儲存樹的成本較低 2. 每次新增時不需要去顧慮是否需要做分裂 tp-Merkle tree 所有的節點都存放在一維陣列中，雖然在初期可能會耗費比較多的儲存空間(若以 21 層樹高為例，需要創建一個陣列長度 221(約 200 萬)的陣列)，但要找到目前的帳戶地址的節點存放在哪一個葉子節點中只要 Index Function 就能快速算出來，一個簡單的字串處理就能算出來，知道索引值的情況下，陣列的搜尋只有時間複雜度 O(1)。而 Jellyfish Merkle tree 每次找一個葉子節點都必須從根節點一個個地向下探索，時間複雜度可能是 O(log n)。 Jellyfish Merkle tree 每次新增都需要判斷是否需要做分裂，但 tp-Merkle tree 在建立樹時就已經完成整棵樹，後續不管是新增或修改都不需要改變樹的結構，因此在這方面的速度也是比 Jellyfish Merkle tree 快上許多。整個數位貨幣系統除了安全性之外，大家最在意的就是每秒交易處理速度，也就是 TPS。要處理交易就必須先找到該帳戶地址(address)所應得葉子節點並修 20.

(28) 改，就以這方面在理論上 tp-Merkle tree 會比 Jellyfish Merkle tree 將會快上許多。. 第四段批次操作原生的 tp-Merkle tree 所處理的環境必須每次進行”put”這個動作時都必須算重新算出一個新的根雜湊(root hash)，然而 Libra 系統是允許做批次處理的，也就是同時修改多個帳戶地址的內容，因此本論文也對 tp-Merkle tree 做稍微的改良，使得 tp-Merkle tree 可以修改一定的帳戶地址內容後在計算出新的根雜湊(root hash)，降低雜湊運算的次數。假設原本該個批次要修改的是 Leaf Node ID5、7、8、15 這些位置，因此只要將這些葉子節點到跟節點之間的內部節點標記起來(下圖灰色的部分)，當該批次結束時，只需要從最上層開始遞迴的找到這些標記起來的節點，並修改完成後算出根節點即可。這些標記起來的節點並不難算，tp-Merkle tree 是一個完滿二元樹結構，因此他一些很方便的特性可以快速的找到父節點，例如下圖有每個節點的上方都有標示數字，那些數字就是表示這些節點在陣列中所存在的位置，像是 Leaf Node ID 為 5 的節點，在陣列中的位置為 21，只要除 2 取整數，得到 10，剛好就是 Leaf Node ID 為 5 的節點的父節點，一直重複做除 2 取整數就可以ㄧ直找的根節點。. 21.

(29) 圖 14 tp-Merkle tree 批次處理範例. 原本要修改一個葉子節點的內容需要進行(𝐻 + 1)次雜湊函數，後面多的那一次為輸入資料取雜湊。所以如果要進行 n 次則為n × (𝐻 + 1)。然而若是使用批次這種作法進行 n 次，若每個要修改的值都剛好在同一個 Pair List 裡面，則僅需要(𝐻 + 𝑛)次雜湊函數，就算最多 n 次要的修改的值都剛好分布在各個 Pair List，最多也只需要(23 − 1) + 2345 + 𝑛。若 n 小於該樹的葉子節點數量(2345 )且平均分佈在葉子節點中，大約的雜湊次數可以用梯形公式表示， (5CD)∗3. 大概為. F. + 𝑛。. 以上面 5 層樹為例子，要修改 16 個值，以非批次需要進行16 × (5 + 1) = 96 次雜湊函式，若使用批次運算僅需最少(5 + 1) = 6次、最多(2H − 1) + 2H45 = 47 次雜湊函數運算，最糟的情況甚至不到非批次的一半。後面實驗結果的地方也會提到使用批次操作和不使用批次操作上執行時間之差異。 22.

(30) 第三節實驗內容該節開始會詳細敘述本論文的實驗目的、方法，以及實驗結果評估的定義。. 第一段實驗目的本論文的實驗目的就是打算替換掉 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. γ：共識投票時間 23.

(31) 因此我們可以估算執行時間(Execution time)為: Execution time =. 𝛼+𝛽+𝑐+𝛾 𝑛. 則內文經常提到的每秒交易量(TPS)則為其倒數： 𝑇𝑃𝑆 =. 1 1 𝑛 = =( ) Execution time (𝛼 + 𝛽 + 𝑐 + 𝛾 ) 𝛼+𝛽+𝑐+𝛾 𝑛. 我們的目的是為了比較 TPS，TPS 越高就表示能在同一時間中處理更多的交易量。TPS 為執行時間之倒數，因此我們希望能有較少的執行時間，在 n 不變的情況下，基本上只要我們能夠降低 α、ß、c 和 γ，我們就能取得少的執行時間。本論文為了能簡單明瞭了分析，本論文使用單個驗證節點的 Libra 架構，減少不穩定而造成的時間上的差異以及共識的時間，並且將客戶端與驗證節點放置在同一台電腦，因此最終我們只會比較”c”的時間，也就是單純比較交易在存入 Merkle tree 後產生根雜湊的執行效率上之差異。. 24.

(32) 第三段實驗步驟. 圖 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. 完成轉帳，公布交易結果. 25.

(33) 在第 2~3 步驟會重複 N 次，用以累積一定的交易數量，用以做批次處理。其中架構中的部件所代表之意義： 1. 帳戶生產器(Generate account)：透過一個函式自動產生大量合法不重複的帳戶地址以及其帳戶資訊內容。 2. 准入控制器(Admission control)：在交易進入驗證節點的交易暫存池之前，會先經過准入控制器，准入控制器會從帳本資料庫取出上個狀態的帳戶資料來判斷帳戶輸出的交易中的內容與資訊是否正確，如付款者的餘額是否足夠，付款者的交易序號是否正確等 3. 交易暫存池(Mempool)：用來暫存待處理的交易內容，驗證節點會在一定時間內取出交易暫存池的內容。 4. Merkle tree：用來計算整個交易帳本完整性的樹狀結構，本論文分別會使用 Jellyfish Merkle tree 和 tp-Merkle tree 兩種，這也是本論文主要比較的地方。 5. 帳本資料庫(DB)：實際儲存交易帳本的位置，不僅儲存樹的節點，也有儲存帳戶的資訊內容。. 第四節使用 tp-Merkle tree 可能遇到的問題第一段碰撞攻擊在 Libra 系統中，客戶端可以自己產生帳戶地址，只要該帳戶地址還未被使用就可以合法使用。後面實驗結果的部分有嘗試這個產生大量具有相同前綴的帳戶地址，產生時間意外的非常快，因此可能會出現惡意的客戶端產生大量具有相 26.

(34) 同前綴的帳戶地址，透過 tp-Merkle tree 的定位函數會將這些大量的帳戶放在同一個葉子節點中。這點會產生一個問題，當其他一般帳戶地址和這些惡意產生帳戶地址存放在相同的葉子節點中時，若需要計算這個葉子節點的雜湊值時，就需要花費比較多的時間，使得處理這些帳戶地址時會比較慢返回交易結果，而且當要驗證這些帳戶地址的合法性時，需要下載比較多的證據，我們將此定義為碰撞攻擊。表 1 在 21 層樹高 100 萬筆帳戶的狀態下模擬碰撞攻擊時被攻擊區和其他區域的修改時間差異. 低碰撞區. 高碰撞(被攻擊)區. 平均. 目標碰. 碰撞. 撞數. 修改總時間. 修改平均時間. 修改總時間. 修改平均時間. 1.55. 1. 23. 0.023. 24. 0.024. 1.55. 10. 23. 0.023. 26. 0.026. 1.55. 100. 23. 0.023. 41. 0.041. 1.55. 1000. 24. 0.024. 197. 0.197. 1.56. 10000. 25. 0.025. 1772. 1.772. 1.66. 100000. 26. 0.026. 17579. 17.579. 其實使用 Jellyfish Merkle tree 時也會有類似的問題，今天假設有一個被攻擊者的帳戶地址是 account a，則攻擊者只需要生成一個和 account a 最後一個字元不同的新的帳戶地址 account a’，迫使 Jellyfish Merkle tree 為 account a 和 account a’ 產生深度最長的內部節點，前面提到當節點的深度越深，要探索的時間就越久，. 27.

(35) 也就是處理這個帳戶地址時會比較慢返回交易結果，目前也沒有論文提到此部分，我們在此也不多加贅述。. 第二段解決方式解決該問題的方法其實非常容易理解與實作，我們只要另外產生一個計數器去紀錄每個葉子節點下所儲存的帳戶數量，當有一個新的帳戶被產生時，該個帳戶地址所對應的葉子節點的帳戶數量高過於某個臨界值時，我們就請客戶端重新產生。以上表為例，平均碰撞 1.55 約在碰撞數 10 左右並沒有明顯增長，直到碰撞數 100 時才有近兩倍明顯的增長，因此可以將這個臨界值設為平均碰撞的 10 倍，也就是當發現帳戶被丟入目前碰撞值為 16 的葉子節點時，我們可以請客戶端重新產生一組帳戶，前面有提到產生帳戶地址這間是非常的快速，且不用花費太多資源，因此我們認為這是一個非常經濟實惠的方法。. 28.

(36) 第四章實驗結果本章節主要分成三個章節，分別介紹 Jellyfish Merkle tree 和 tp-Merkle tree 各自的操作實驗結果，最後第三節則會比較 Jellyfish Merkle tree 和 tp-Merkle tree 兩者之比較。其中第二節介紹 tp-Merkle tree 的部分還會提到使用批次的和原本不使用批次之比較，以及碰撞高低對 tp-Merkle tree 之影響。本論文使用 Java 來實作我們的實驗內容，使用的電腦作業系統為 Windows 10，處理器為 Inter Core i5-8500CPU @3.00GHz，記憶體為 32GB。以下內容所提到的雜湊運算使用 java.security.MessageDigest 中的 SHA-256 algorithm 。耗費記憶體是指 Java 執行階段所佔用的記憶體，透過 java.lang.Runtime.totalMemory 減去 java.lang.Runtime.freeMemory 所計算而來。耗費儲存空間是將該結構樹的結構包含帳戶資料透過 java.io.ObjectOutputStream 打包成一個資料，再去看他的資料大小。. 29.

(37) 第一節 Jellyfish Merkle tree 實驗結果下表為 Jellyfish Merkle tree 將預先準備好的 1 萬、10 萬、100 萬和 1000 萬筆資料塞進樹裡面的時間、記憶體耗費與儲存空間耗費。表 2 Jellyfish Merkle tree 創建 1 萬~1000 萬筆資料時間、耗費記憶體與硬碟儲存空間. 資料數. 創建時間(ms). 1萬. 4054.0654. 10. 2. 10 萬. 39070.6914. 98. 28. 100 萬. 481358.1045. 951. 279. 1000 萬. 5215420.0148. 9435. 2752. 總耗費記憶體(MB). 總耗費儲存(MB). 下表為 Jellyfish Merkle tree 將預先準備好的 1 萬、10 萬、100 萬和 1000 萬筆資料塞進樹裡面的平均深度、最小深度與最大深度。表 3 Jellyfish Merkle tree 創建 1 萬~1000 萬筆平均深度、最小深度與最大深度. 資料數. 平均深度. 最小深度. 最大深度. 1萬. 4.0596. 3. 7. 10 萬. 4.8812. 4. 9. 100 萬. 5.6736. 4. 12. 1000 萬. 7.2524. 4. 12. 30.

(38) 下表為 Jellyfish Merkle tree 在已經存在 1 萬、10 萬、100 萬和 1000 萬筆資料在樹中時執行 1000 筆交易時間。表 4 修改 1 萬~1000 萬筆資料時間以及每秒平均修改次數. 修改時間 (ms). 每秒平均修改次數. 1萬. 814.3859. 1228. 10 萬. 810.5920. 1234. 100 萬. 994.6541. 1005. 1000 萬. 980.5833. 1020. 資料數. 在儲存和記憶體方面，從表 2 可得知，Jellyfish Merkle tree 的儲存和記憶體會隨著資料筆數的增加，而成線性的成長。另外在修改時間方面，從表 4 可以發現，Jellyfish Merkle tree 的每秒平均修改次數從 1200 慢慢降到約 1000 左右。. 31.

(39) 第二節 tp-Merkle tree 實驗結果第一段批次測試下表分別是樹高 17、21 和 25 中，存在 100 萬筆資料下修改 2000 筆資料之非批次與批次之比較。非批次取雜湊的次數是固定的，都可以用𝑛 × (𝐻 + 1)這個公式求得。而批次去雜湊次數都會介於(𝐻 + 𝑛)到(23 − 1) + 2345 + 𝑛之間，基本上只要修改筆數(n)沒有超過樹的葉子節點個數(2345 )，就很難達這個雜湊次數的上限值。表 5 tp-Merkle tree 樹高 17~25 非批次修改時間與取雜湊次數. 樹高(H). 修改筆數(n). 修改時間(ms). 取雜湊次數. 17. 2000. 158.7914. 36000. 21. 2000. 189.5270. 44000. 25. 2000. 570.4985. 52000. 表 6 tp-Merkle tree 樹高 17~25 批次修改時間與取雜湊次數. 樹高(H). 修改筆數(n). 修改時間(ms). 取雜湊次數. 17. 2000. 109.8627. 12375. 21. 2000. 112.0445. 20271. 25. 2000. 126.2101. 28278. 32.

(40) 第二段不同樹高分析以下的內容為 13~25 層樹高下的將預先準備好的 1000 萬筆資料塞進樹裡面的時間、記憶體耗費與儲存空間耗費。表 7 tp-Merkle tree 13~25 層樹高創建 1000 萬筆資料時間、耗費記憶體與硬碟儲存空間. 樹高. 創建時間(ms). 總耗費記憶體(MB). 總耗費儲存(MB). 13. 64657.00251. 4086. 802. 14. 63798.50681. 4088. 803. 15. 61877.12326. 4093. 805. 16. 60931.36753. 4102. 810. 17. 60662.55156. 4121. 818. 18. 63474.94208. 4159. 836. 19. 63432.18024. 4236. 871. 20. 70766.91953. 4388. 942. 21. 66563.69339. 4694. 1083. 22. 76972.74355. 5345. 1365. 23. 85576.16808. 6622. 1929. 24. 97826.76404. 8982. 3057. 25. 116746.1197. 13374. 5313. 33.

(41) 以下的內容為 13~25 層樹高下的將預先準備好的 1000 萬筆資料塞進樹裡面的平均碰撞次數、最小碰撞次數和最大碰撞次數。碰撞指的是在 Pair List 中的帳戶數量。表 8 tp-Merkle tree 13~25 層樹高創建 1000 萬筆平均碰撞、最小碰撞和最大碰撞. 樹高. 平均碰撞. 最小碰撞. 最大碰撞. 13. 2441.4062. 2250. 2608. 14. 1220.7031. 1094. 1355. 15. 610.35156. 517. 709. 16. 305.17578. 227. 386. 17. 152.58789. 102. 205. 18. 76.293945. 39. 114. 19. 38.146973. 12. 72. 20. 19.073486. 1. 42. 21. 9.53738. 0. 27. 22. 4.809186. 0. 19. 23. 2.626494. 0. 14. 24. 1.7115266. 0. 10. 25. 1.3275497. 0. 8. 34.

(42) 以下的內容為 13~25 層樹高下在已經存在 1000 萬筆資料下，執行 10000 筆交易的平均時間。表 9 tp-Merkle tree 13~25 層樹高修改 1000 萬筆資料時間以及每秒平均修改次數. 樹高. 修改時間 (ms). 每秒平均修改次數. 13. 893.8062. 1119. 14. 509.8560. 1961. 15. 320.4231. 3120. 16. 228.4066. 4378. 17. 159.6762. 6263. 18. 141.2708. 7079. 19. 122.6480. 8153. 20. 113.3324. 8824. 21. 112.4221. 8895. 22. 114.1943. 8757. 23. 116.3491. 8595. 24. 118.2166. 8459. 25. 121.4042. 8237. 35.

(43) tp-Merkle tree 的樹高是由資料筆數來決定，根據前面的數據（表 7、表 8、表 9）可以畫出如下圖，可以明顯發現約 18~22 層樹高的區間，修改趨近最低點，並且耗費的記憶體和和費的儲存空間還沒開始明顯的上升，其中在約 21 層的地方修改時間來到最低值，因此後面比較使用 21 層來做比較。. 圖 17 tp-Merkle tree 樹高分析. 第三節 Jellyfish Merkle tree 與 tp-Merkle tree 結果比較以下實驗都是預先在存放有 100 萬及 1000 萬筆帳戶資訊，並且取 1000 次交易去執行，其中 tp-Merkle tree 使用的是 21 層且是批次處理版本。表 10 兩種樹創建 100 萬的執行時間、耗費記憶體及耗費儲存空間之比較. Jellyfish Merkle tree tp-Merkle tree. 創建時間(ms). 總耗費記憶體(MB). 總耗費儲存(MB). 481358.1045. 951. 279. 9063.4793. 1030. 372. 36.

(44) 表 11 兩種樹創建 1000 萬的執行時間、耗費記憶體及耗費儲存空間之比較. Jellyfish Merkle tree tp-Merkle tree. 創建時間(ms). 總耗費記憶體(MB). 總耗費儲存(MB). 5215420.0148. 9435. 2752. 66563.6933. 4710. 1093. 表 12 兩種樹在已經存在 100 萬執行 1000 筆帳戶餘額修改時間及每秒平均修改次數. 修改時間 (ms). 每秒平均修改次數. Jellyfish Merkle tree. 994.654124. 981. tp-Merkle tree. 112.044543. 8925. 表 13 兩種樹在已經存在 1000 萬執行 1000 筆帳戶餘額修改時間及每秒平均修改次數. 修改時間 (ms). 每秒平均修改次數. Jellyfish Merkle tree. 980.583283. 1020. tp-Merkle tree. 112.422122. 8895. 在儲存空間和記憶體上，由表 10 和表 11 可發現，在 tp-Merkle tree 在 100 萬筆中雖然略高於 Jellyfish Merkle tree ，但在 1000 萬筆時 tp-Merkle tree 卻少於 Jellyfish Merkle tree 快三倍。另外在修改時間上，有表 12 和表 13 中可觀察到，不管是 100 萬筆還是 1000 萬筆，tp-Merkle tree 都快 Jellyfish Merkle tree 約 9 倍。. 37.

(45) 第五章結論雖然近期數位貨幣或是加密貨幣在市面上越來越多，但可能因為規模通常都不太大，且整體規劃不太良善，導致普遍不受到一般政府和管理貨幣的央行所注意。但這次擁有 20 億活躍人口的 Facebook 主導推出的他們得數位貨幣 Libra 後，光是推出白皮書還沒正式上線，就立刻受到各國政府與銀行單位所打壓，話雖如此，但也表示數位貨幣已經受到各國政府與銀行單位所關注。排除政府與銀行單位的打壓，身為需要容納 20 億活躍用戶的一個數位貨幣系統在每秒交易量(TPS)上可能是不太足夠的，但如果使用我們實驗室的方案來儲存整體帳本狀態，可以讓帳本的每秒修改次數大幅提升，進而可能降低 Libra 的每秒交易量(TPS)。藉由實驗的結果可以得知本實驗室的 tp-Merkle tree 和 Jellyfish Merkle tree 在修改葉子節點的值下有更快的處理速度，相對的若 Libra 使用 tp-Merkle tree 來儲存整體帳本狀態的話，相信是可以有更好的 TPS 數據，為未來的貨幣數位化踏出巨大的一步。. 38.

(46) 參考文獻 [1] Libra Association. "Libra white paper." Internet access:,[accessed June 19, 2019] (2019). [2] Facebook Reports First Quarter 2020 Results： https://investor.fb.com/investor-news/press-release-details/2020/FacebookReports-First-Quarter-2020-Results/default.aspx [3] LibExplorer：https://libexplorer.com/# [4] Zhang, Jiashuo, et al. "Performance Analysis of the Libra Blockchain: An Experimental Study." arXiv preprint arXiv:1912.05241 (2019). [5] Hash function：https://en.wikipedia.org/wiki/Hash_function [6] Merkle, Ralph C. "Method of providing digital signatures." U.S. Patent No. 4,309,569. 5 Jan. 1982. [7] Baudet, Mathieu, et al. "State machine replication in the Libra Blockchain." (2019). [8] Hwang, Gwan-Hwan, and Hung-Fu Chen. "Efficient real-time auditing and proof of violation for cloud storage systems." 2016 IEEE 9th International Conference on Cloud Computing (CLOUD). IEEE, 2016. [9] libra/storage/jellyfish-merkle at master · libra/libra： https://github.com/libra/libra/tree/master/storage/jellyfish-merkle [10] Visa Q4 2019 Earnings Call： https://s1.q4cdn.com/050606653/files/doc_financials/2019/q4/CORRECTEDTRANSCRIPT-Visa,-Inc.(V-US),-Q4-2019-Earnings-Call,-24-October-2019-500-PM-ET.pdf [11] 騰訊 2019 年度報告： https://cdc-tencent-com1258344706.image.myqcloud.com/uploads/2020/04/02/ef47087db40a44f5b1bd6 5334f3a52e4.pdf 39.

(47)