區塊鏈中介服務設計探討-以Ethereum為例 - 政大學術集成
80
0
0
全文
(2) 區塊鏈中介服務設計探討-以 Ethereum 為例 Blockchain Middleware Design Base on Ethereum Platform. 研 究 生:蔡詠捷. Student:Yung-Chieh Tsai. 指導教授:陳 恭. Advisor:Kung Chen. 國立政治大學 資訊科學系 碩士論文. A Thesis submitted to Department of Computer Science National Chengchi University in partial fulfillment of the Requirements for the degree of Master in Computer Science. 中華民國一百零六年七月 July 2017.
(3)
(4)
(5) 記錄編號:G1049710031. 國立政治大學 博碩士論文全文上網授權書 National ChengChi University. Letter of Authorization for Theses and Dissertations Full Text Upload (提供授權人裝訂於紙本論文書名頁之次頁用) (Bind with paper copy thesis/dissertation following the title page). 本授權書所授權之論文為授權人在國立政治大學資訊科學系碩士在職專班系所 ________________組 105學年度第二學期取得 碩士學位之論文。 This form attests that the _____________ Division of the Department of Excutive Master Program of Computer Science of NCCU at National ChengChi University has received a Master degree thesis/dissertation by the undersigned in the _________ semester of 105 academic year. 論文題目(Title):區塊鏈中介服務設計探討-以Ethereum為例 ( Blockchain Middleware Design Base on Ethereum Platform ) 指導教授(Supervisor):陳恭 立書人同意非專屬、無償授權國立政治大學,將上列論文全文資料以數位化等各種方式重 製後收錄於資料庫,透過單機、網際網路、無線網路或其他公開傳輸方式提供用戶進行線 上檢索、瀏覽、下載、傳輸及列印。 國立政治大學並得以再授權第三人進行上述之行為。 The undersigned grants non-exclusive and gratis authorization to National ChengChi University, to re-produce the above thesis/dissertation full text material via digitalization or any other way, and to store it in the database for users to access online search, browse, download, transmit and print via single-machine, the Internet, wireless Internet or other public methods. National ChengChi University is entitled to reauthorize a third party to perform the above actions. 論文全文上載網路公開之時間(Time of Thesis/Dissertation Full Text Uploading for Internet Access): 網際網路(The Internet) ■ 立即公開 ● 立書人擔保本著作為立書人所創作之著作,有權依本授權書內容進行各項授權,且未侵 害任何第三人之智慧財產權。 The undersigned guarantees that this work is the original work of the undersigned, and is therefore eligible to grant various authorizations according to this letter of authorization, and does not infringe any intellectual property right of any third party. ● 依據96年9月22日96學年度第1學期第1次教務會議決議,畢業論文既經考試委員評定完 成,並已繳交至圖書館,應視為本校之檔案,不得再行抽換。關於授權事項亦採一經授權 不得變更之原則辦理。 According to the resolution of the first Academic Affairs Meeting of the first semester on September 22nd, 2007,Once the thesis/dissertation is passed after the officiating examiner's evaluation and sent to the library, it will be considered as the.
(6)
(7) 誌 謝 能夠在職場多年後重新回到學校,並取得碩士學位完成一個重要的里 程,我非常感謝我的父母、太太還有兒子的支持與鼓勵,為我分擔許多家 庭的責任,讓我無顧慮的在學業及研究上。 我非常感謝陳恭老師,帶領我進入區塊鏈的領域,引導我更廣闊的思 維,不論在課業上或者研究上,學習了許多在職場多年未曾涉獵的技術與 知識,經過此次論文的訓練,讓我各方面的思維均向上提升一個層次,研 究的過程中與陳恭老師的互動讓我深刻了解,做研究需要嚴謹與專注,了 解所有技術背後的設計思維與價值。目前全球的區塊鏈尚處於一個萌芽階 段,這也是一個重要的開端,引領這個世界走向去中心化的未來。. I.
(8) 區塊鏈中介服務設計探討-以 Ethereum 為例. 摘要 隨著近年來區塊鏈的興起與發展,許多軟體開發商認識到區塊鏈的技術。 其特色可以帶來改變世界的巨大價值,遂投入區塊鏈技術的研究與開發。 而眾多數位貨幣中最有潛力的莫過於 Ethereum 所提出的智能合約,因此, 如何快速簡單的開發 Ethereum 上的智能合約以及去中心化的應用程式,將 會是一個帶動區塊鏈加速發展的重要因素。 為了讓開發人員能夠快速部署及測詴智能合約,並且簡化開發去中心化應 用程式的複雜度,本研究提出區塊鏈中介服務的軟體框架建構方式與實作 流程,在開發去中心化應用程式時,讓開發人員僅著重於開發應用程式的 邏輯判斷,不需要再花時間去部署以及設定 Ethereum 的核心程式,透過本 研究所提供的服務,可以直接將 Ethereum 視為一個後端伺服器,透過用 API 串接的方式與應用程式交互溝通。本研究所提出的區塊鏈軟體中介服務經 過技術的封裝,開發人員不需要了解區塊鏈底層核心的相關技術,就能完 成去中心化應用程式的開發。 關鍵字:區塊鏈、以太坊、中介元件. II.
(9) Blockchain Middleware Design Based on Ethereum Platform. Abstract With the rise and development of blockchain in recent years, many software developers have realized that the technology of blockchain can bring great value to change the world, thus put into research and development of blockchain technology. Technology with highest potential is Ethereum with the smart contract. Therefore, how to quickly and easily develop Ethereum smart contract and develop the decentralized application will be an important factor to the growth of blockchain. In order to enable developers to quickly deploy and testing smart contracts, and to simplify the complexity of the development of decentralized application, this thesis proposed blockchain middleware, software architecture and implementation process. For using this middleware, developer only need to focus on the logic of the application during the development phase, they do not need to spend a lot of time to deploy and set the core program in Ethereum. Through this middleware to provide services, developer can use Ethereum as a backend server, through the communication API in of the middleware. In this research, the blockchain middleware is encapsulated by the technology, developer can complete development of the decentralized application without knowing the related technology of the core of the blockchain. Keywords: Blockchain、Ethereum、Middleware III.
(10) 目錄 第一章 緒論 .................................................................................. 1 1.1 1.2 1.3. 研究背景與動機 .................................................................................................... 1 研究目的 ................................................................................................................ 2 研究貢獻 ................................................................................................................ 2. 第二章 相關研究與技術背景........................................................ 3 2.1. 區塊鏈 .................................................................................................................... 3 2.1.1 2.1.2 2.1.3. Consensus ................................................................................................... 4 Consistent Hashing ..................................................................................... 5 P2P Network ............................................................................................... 6. 2.1.4 Digital Signature.......................................................................................... 6 2.2 Ethereum ................................................................................................................ 7 2.2.1 Web3........................................................................................................... 7 2.2.2 Ethereum Virtual Machine ......................................................................... 8 2.2.3 Decentralized Application ........................................................................... 8 2.3 2.4 2.5 2.6 2.7. 2.2.4 Smart Contract ............................................................................................ 9 Message Oriented Middleware .............................................................................. 9 PostgreSQL ............................................................................................................ 10 Elasticsearch ......................................................................................................... 11 Docker ................................................................................................................... 11 Swagger ................................................................................................................ 12 2.7.1 Open API 規範 .......................................................................................... 12. 2.8. BlockApps ............................................................................................................. 13 2.8.1 BlockApps STRATO Architecture ............................................................... 14 2.9 Etherscan .............................................................................................................. 16. 第三章 區塊鏈中介元件軟體設計探討....................................... 16 3.1. BlockChainBox 架構設計 ..................................................................................... 17 3.1.1 連線至區塊鏈網路 .................................................................................. 18 3.1.2 開發人員 Ethereum 地址管理 ................................................................ 18 3.1.3 3.1.4 3.1.5 3.1.6. 智能合約部署與管理 .............................................................................. 19 管理區塊鏈智能合約與交易之間的關聯性資訊 .................................. 19 區塊鏈交易的失敗處理 .......................................................................... 19 區塊鏈的非即時處理導致外部頻繁呼叫 Ethereum 的問題 ................ 20 IV.
(11) 3.2. BlockChainBox 模組化設計 ................................................................................. 21 3.2.1 Message Oriented Middleware 實作 ....................................................... 22 3.2.2. Docker 導入 .............................................................................................. 24. 3.2.3 3.2.4 3.2.5 3.2.6 3.2.7 3.2.8 3.2.9 3.2.10 3.2.11. Account Management .............................................................................. 24 Ethereum Gateway ................................................................................... 25 Contract Handler ...................................................................................... 27 Transaction Handler .................................................................................. 31 Event Handler ........................................................................................... 33 Webhook Support ..................................................................................... 35 Ethereum Explorer .................................................................................... 37 Swagger UI ................................................................................................ 41 Docker Support ......................................................................................... 42. 第四章 區塊鏈中介元件軟體使用探討....................................... 43 4.1 4.2 4.3. 4.4 4.5 4.6 4.7 4.8. Account Management .......................................................................................... 43 Ethereum Gateway ............................................................................................... 44 Contract Handler .................................................................................................. 45 4.3.1 Contract Function ..................................................................................... 46 4.3.2 Contract Event .......................................................................................... 46 Transaction Handler .............................................................................................. 46 Event Handler ....................................................................................................... 47 Webhook............................................................................................................... 47 Ethereum Explorer ................................................................................................ 47 效能測詴 .............................................................................................................. 48. 4.8.1 Amazon Web Service ................................................................................ 49 4.8.2 測詴環境 .................................................................................................. 49 4.9 系統比較 .............................................................................................................. 51 4.9.1 系統使用性與操作性比較 ...................................................................... 53 4.9.2 比較 Webhook、WebSocket 與 Long Polling .......................................... 54 4.10 系統使用情境 .................................................................................................. 55 4.10.1 API 操作流程範例 .................................................................................... 55 4.10.2 範例程式 .................................................................................................. 57. 第五章 結論與未來研究方向...................................................... 60 5.1 5.2. 結論 ...................................................................................................................... 60 未來研究方向 ...................................................................................................... 61 5.2.1 跨區塊鏈的功能 ...................................................................................... 61 V.
(12) 5.2.2 5.2.3. 提供 SDK 支援 .......................................................................................... 61 提供 WebSocket 支援 .............................................................................. 61. 參 考 文 獻 ........................................................................... 62 附 錄 ………………………………………………………………………………………65. VI.
(13) 圖目錄 圖 2.1 區塊鏈示意圖,本圖取自【5】 ................................................................... 3 圖 2.2 Proof of Work vs Proof of Stake,本圖取自【13】....................................... 5 圖 2.3 Digital Signature,本圖取自【14】............................................................... 7 圖 2.4 Solidity 程式語言範例,本圖取自【24】 .................................................... 8 圖 2.5 Smart Contract,本圖取自【4】 ................................................................... 9 圖 2.6 Message Oriented Middleware,本圖取自【12】 ..................................... 10 圖 2.7 Docker Engine,本圖取自【18】 ................................................................ 12 圖 2.8 API 概念圖,本圖取自【10】 .................................................................... 13 圖 2.9 BlockApps STRATO,本圖取自【9】 ........................................................... 14 圖 2.10 BlockApps 介面,本圖取自【9】 ............................................................. 14 圖 2.11 BlockApps 架構圖,本圖取自【9】 ......................................................... 15 圖 3.1 BlockChainBox Middleware 概念圖 .............................................................. 17 圖 3.2 BlockChainBox 架構圖 .................................................................................. 20 圖 3.3 BlockChainBox 模組設計圖 .......................................................................... 22 圖 3.4 BlockChainBox Message Oriented Middleware ............................................ 23 圖 3.5 BlockChainBox Docker Containers 示意圖 .................................................... 24 圖 3.6 使用者帳戶與以太坊地址資料庫關聯圖 .................................................. 25 圖 3.7 API Gateway 架構圖 ...................................................................................... 26 圖 3.8 TransactionData Table Schema ...................................................................... 27 圖 3.9 Contract Table Schema .................................................................................. 28 圖 3.10 Contract Handler Flow ................................................................................. 29 圖 3.11 Contract Function 關聯圖 .......................................................................... 30 圖 3.12 Contract Event 關聯圖 ................................................................................ 31 圖 3.13 Transaction Handler Flow ............................................................................ 32 圖 3.14 Event Handler Flow ...................................................................................... 34 圖 3.15 Event Table Schema ..................................................................................... 35 圖 3.16 Webhook Handler Flow ............................................................................... 36 圖 3.17 WebhookData Table Schema ....................................................................... 37 圖 3.18 使用 BlockChainBox Explorer 搜尋 Contract ............................................. 39 圖 3.19 使用 etherscan.io 搜尋 Contract ............................................................... 40 圖 3.20 BlockChainBox Explorer Service 架構圖 ..................................................... 41 圖 3.21 Swagger 介面圖 .......................................................................................... 42 圖 4.1 Account Management API ............................................................................. 43 圖 4.2 Ethereum Gateway API .................................................................................. 45 圖 4.3 Contract Handler API ..................................................................................... 46 VII.
(14) 圖 4.4 Ethereum Explorer API .................................................................................. 48 圖 4.5 Amazon EC2 規格 .......................................................................................... 50 圖 4.6 Amazon EC2 Instance..................................................................................... 50 圖 4.7 BlockChainBox 與 BlockApps 比較表............................................................ 52 圖 4.8 Ethereum middleware 與 Web3 Libaray 比較表 .......................................... 54 圖 4.9 Webhook、WebSocket 與 Long Polling 比較表 ........................................... 55 圖 4.10 流程圖圖解(一).......................................................................................... 56 圖 4.11 流程圖圖解(二).......................................................................................... 57 圖 4.12 範例程式首頁 ............................................................................................ 58 圖 4.13 範例程式新增清單,並發送一筆交易至 Ethereum 區塊鏈 .................. 58 圖 4.14 範例程式列出所有交易 ............................................................................ 59 圖 4.15 範例程式列出所有 Event .......................................................................... 59. VIII.
(15) 程式碼目錄 程式碼 3.1 Access Token 產生方式 ......................................................................... 25. IX.
(16) 第一章. 緒論. 隨著近年來區塊鏈的興起與發展,不少以區塊鏈為基礎的數位貨幣由然而生。許多軟體 開發商看準了區塊鏈的特色及優勢,紛紛投入區塊鏈技術的研究與開發,充分顯示區塊 鏈技術已經成為資訊產業下一個重點發展項目。區塊鏈主要的特色為去中心化與資料的 不可竄改性,每一個參與區塊鏈網路的節點都依循著共識來寫入鏈上的帳本,並且在寫 入後與所有節點進行同步,以達成去中心化與資料的不可竄改性。其中以 Ethereum 所 提出的智能合約(Smart Contract)最受眾人矚目,智能合約的出現讓許多現實上複雜的合 約可以透過去中心化網路來協助驗證,並且減少人為造成的錯誤。然而加入 Ethereum 網路需要個別架設節點,才可以進行一般交易與合約交易。有鑒於此,本研究提出區塊 鏈中介服務的軟體框架建構方式與實作流程。. 1.1. 研究背景與動機. 科技不斷日新月異,網路上也有越來越多種支付方式開始興起,因此,接觸到了比特幣 這種新的支付方式。經過廣泛的閱讀與研究,了解到了區塊鏈技術最一開始是發源於自 比特幣為了建構其底層分散式帳本的一種技術。自從 2008 年起比特幣被發明之後,底 層區塊鏈技術就不斷的演進,在 2015 年底時誕生了由以太坊基金會所建構出的 Ethereum 區塊鏈,他最大的不同點是將一種虛擬機架構在區塊鏈上,稱之為 Ethereum Virtual Machine (EVM)。EVM 有著各種原生語言可以撰寫程序於虛擬機上執行,並且透 過所有遍佈在世界各地參與 Ethereum 區塊鏈的節點來進行驗證。運行於虛擬機上的程 序又稱之為智能合約(Smart Contract),可以將任意合約部署於 Ethereum 區塊鏈上,並且 可以透過調用的方式將資料與區塊鏈進行溝通,因此,智能合約的應用在不遠的將來對 於區塊鏈是一個非常有發展性的技術。 在 Ethereum 區塊鏈學習的過程中,發現到開發者要在 Ethereum 區塊鏈上進行開發並且 部署智能合約(Smart Contract)其實並不容易,開發者需要先行下載可運行 Ethereum 區 1.
(17) 塊鏈的分散式系統程式 go-ethereum,並且透過 go-ethereum 同步 Ethereum 區塊鏈節點 的資料後才可以使用 Ethereum 的各種功能,再來如果需要使用已經開發好的 Ethereum 去中心化應用程序就必頇要額外下載該軟體,並且安裝在需要使用該軟體的電腦上。這 些過程的複雜度對於一般開發者不太容易掌握,甚至對一般使用者想要使用去中心化應 用程序的門檻過高,大大增加了使用與開發上的困難度。 因此,投入研究 Ethereum 區塊鏈中介服務軟體框架相關技術的研究,未來對一般開發 者在使用與開發上將會是一大助益。. 1.2. 研究目的. Ethereum 區塊鏈在未來的發展上將是一種不可或缺的技術。因此,為了使 Ethereum 區 塊鏈中介服務軟體框架,可以讓一般開發團隊能以簡易的操作方式透過智能合約開發與 部署,因應各種軟體服務來進行相對應的設計,讓開發者在 Ethereum 中介軟體框架開 發去中心化應用程式的過程中不僅不需要考量如何設定與部署 Ethereum 區塊鏈,甚至 能讓開發團隊在不需要了解太多複雜的 Ethereum 區塊鏈技術下能夠完成應用程式開發, 因此,簡化佈署智能合約的流程與複雜度將是一個重要的課題。. 1.3. 研究貢獻. 本研究提出區塊鏈中介服務的軟體框架概念與實作,將 Ethereum 區塊鏈中的各項功能 包裝在系統中,讓開發者可以更專注地針對去中心化應用程序進行開發。另外也提供區 塊鏈上各種資訊的查詢服務,使用者可以透過此系統,大幅降低開發者踏入區塊鏈的難 度。. 2.
(18) 第二章 2.1. 相關研究與技術背景. 區塊鏈. 區塊鏈的概念是由 Satoshi Nakamoto 在 2008 年所提出。區塊鏈是一種共享式的公開帳 本,採用分佈式分類帳技術,將資料散布於各個區塊中,使資料無法被單一實體所掌控, 讓交易資料具備安全、透明、可永久記錄等特性。區塊鏈本身維護不斷增長的記錄列表 稱之為區塊,每一個區塊中包含了時間戳記與前一個區塊的鏈接,透過這種方式可以使 區塊中的資料不能被追溯與修改。比特幣則是一種區塊鏈技術的實際應用,其原理是由 數個節點組成一個網路,當其中某一個節點發起一筆交易時,這節點會將此交易傳遞給 其它的節點,而所有節點皆可以透過共識演算法決定誰可以驗證這筆交易。 2014 年區塊鏈技術有著顯著的提升,稱之為 Blockchain 2.0,指的是分佈式區塊鏈資料 庫的新應用術語。第二代區塊鏈衍伸出了實現可撰寫程式語言於區塊鏈上的一種應用, 即一種區塊鏈上的程式語言,允許使用者撰寫更為複雜的智能合約,從而創建一些商業 化的應用,這些應用還能包含到貨時一併遞交發票,分享憑證,甚至當股息到達一定水 準之後,系統會將利潤自動發送至股票所有者。Blockchain 2.0 技術超越了一般傳統交易 模式,達成了沒有中介機構作為貨幣和信息仲裁者的價值交換核心。不但可以排除人為 因素涉入全球經濟,也可以保護隱私和人民,並提供確保創作者獲得知識產權的能力。. 圖 2.1 區塊鏈示意圖,本圖取自【5】. 3.
(19) 2.1.1. Consensus. Proof of Work:工作量證明是為了讓每個參與的節點能共同參與交易的驗證。也是一個 能多方共同維護並共享同一份交易紀錄的帳本。在工作量證明中,記帳節點需要使用一 定的運算資源來處理同一條件的 Hashcash 來計算,哪一個節點先計算出來,該區塊就 屬於該節點的,接著算出的數值則可向其它節點提交計算的工作量證明。 雖然 Hashcash 難以被破解,但是很容易能被其它節點驗證。產生工作量證明是一個非 常低概率的隨機過程,因此,在生成有效的工作量證明之前,需要大量的嘗詴與失敗。 工作量證明這個想法一開始的應用是使用 Hashcash 作為防止垃圾郵件的一種方法,其 作法是需要在每封電子郵件上對電子郵件的內容進行工作量證明。合法的電子郵件將能 夠輕鬆地生成證據,個別的電子郵件不需要太多的工作量即可產生,但大規模垃圾郵件 發送者將難以產生所需的證明,因為此過程會使垃圾郵件將需要耗費大量的計算資源。 比特幣中使用了 Hashcash 的工作量證明來產生區塊,當網路上所有參與者要產生區塊 時,所有參與者們必頇完成區塊中所有資料的工作量證明。然而比特幣網路中這項計算 工作的難度,是透過限制比特幣網路每 10 分鐘只允許產生一個新區塊的速率而浮動調 整。由於計算成功的可能性非常低,這使得網路中不管哪一個參與者或者計算機產生下 一個區塊是不可預測的。要使區塊有效,它必頇透過計算 Hash 找到小於當前目標的值, 這表示每個區塊已經完成了工作。由於每個區塊包含前一塊的 Hash,因此,每個區塊具 有一起包含大量工作的區塊鏈。. Proof of Stake:權益證明是數位貨幣另一種共識機制,與基於工作量證明的加密貨幣不 同(如:比特幣)。此種演算法並不在於解決複雜的加密問題,也不是透過驗證交易和創建 新區塊而獲得獎勵。權益證明的演算法中是以確定性或偽隨機的方式選擇下一個區塊, 而選擇一個參與者帳號的機會取決於其手上的貨幣價值。通常所有的硬幣都是在開始創 建的,硬幣的總數從不改變。因此,在權益證明的演算法中,並沒有所謂的區塊獎勵。. 4.
(20) 圖 2.2 Proof of Work vs Proof of Stake,本圖取自【13】. 2.1.2. Consistent Hashing. Consistent Hashing 又稱為一致性雜湊算法,是由麻省理工學院的 Karger 及其合作者於 1997 年所提出的一種分散式雜湊表(Distributed Hash Table, DHT)的實現算法,使得分 散式雜湊表(DHT)可以在 P2P 環境中真正得到應用。以下為判定雜湊算法好壞的四個 定義: (1) 平衡性(Balance):平衡性是指雜湊的結果能夠盡可能分佈到所有的緩衝中,這樣 可以使得所有的緩衝空間都得到利用,很多雜湊算法都能夠滿足這一條件。 (2) 單調性(Monotonicity) :單調性是指如果已經有一些內容通過雜湊分派到了相應的 緩衝中,又有新的緩衝加入到系統中,雜湊的結果應能夠保證原有已分配的內容可 5.
(21) 以被映射到原有的或者新的緩衝中,而不會被映射到舊的緩衝集合中的其它緩衝 區。 (3) 分散性(Spread):在分佈式環境中,終端有可能看不到所有的緩衝,而是只能看 到其中的一部分當終端希望通過雜湊過程將內容映射到緩衝上時,由於不同終端所 見的緩衝範圍有可能不同,從而導致雜湊的結果不一致,最終的結果是相同的內容 被不同的終端映射到不同的緩衝區中。這種情況顯然是應該避免的,因為它導致相 同內容被儲存到不同緩衝中去,因而降低了系統存儲的效率。分散性的定義就是上 述情況發生的嚴重程度。好的雜湊算法應能夠盡量避免不一致的情況發生,也就是 盡量降低分散性。 (4) 負載(Load):負載問題實際上是從另一個角度看待分散性問題既然不同的終端可 能將相同的內容映射到不同的緩衝區中,那麼對於一個特定的緩衝區而言,也可能 被不同的用戶映射為不同的內容。與分散性一樣,這種情況也是應當避免的,因此, 好的雜湊算法應能夠盡量降低緩衝的負荷。. 2.1.3. P2P Network. 根據比特幣的協議,區塊鏈是採用一種無結構的 P2P 網路。P2P 網路分為有結構和無結 構兩種,區別在於路由規則的制定方面。有結構的 P2P 網路,利用一致性雜湊表建構每 一個節點的路由表;無結構的 P2P 網路,則是節點之間的路由靠廣播的方式,也就是說 一個節點想查找一個文件,他就問他的鄰居有沒有這個文件,他的鄰居再問各自的鄰居 有沒有,如此疊代。這樣的方式容易形成廣播風暴,因此,一般會設置 TTL(Time to live), 來限制廣播傳播的範圍來解決這個問題。. 2.1.4. Digital Signature. 數位簽章是透過橢圓曲線加密技術的公私鑰來實現。其中包含著兩個概念: 公私鑰是非對稱加密技術,公鑰是可以公佈在外的一組金鑰,而私鑰則需要自己妥善保 6.
(22) 存,公私鑰的生成方式,是基於私鑰生成時產生相對應的公鑰。 公鑰加密的資訊則需要對應的私鑰才能解密。而相對的,私鑰加密的內容,則需要由該 私鑰產生出來的公鑰才能解密。 數位簽章整個概念主要是透過私鑰將要發送出去的訊息進行加密,然後透過公鑰進行驗 證與解密,如果驗證原訊息與透過私鑰加密過後的訊息是相同的,則此訊息可以驗證為 該私鑰擁有者的數位簽章。. 圖 2.3 Digital Signature,本圖取自【14】. 2.2. Ethereum. Ethereum 也稱之為以太坊,是一個基於區塊鏈去中心化的應用平台,它將比特幣區塊鏈 技術擴充並加入 EVM 中,補齊了比特幣區塊鏈並沒有支援圖靈完備性,以便開發者將 自己的去中心化應用運行在區塊鏈上。它是一種不同類型的區塊鏈應用程式的平台,不 僅限於單純的加密貨幣。. 2.2.1. Web3 7.
(23) Web3 是透過 JavaScript 實現 RPC 規範的 Ethereum API。它可以嵌入各種 JavaScript Framework 中作為元件使用。. 2.2.2. Ethereum Virtual Machine. Ethereum Virtual Machine 又稱為 EVM,是基於 Ethereum 一種可以編寫程式的區塊鏈, 它並不像比特幣會給予使用者一組事先定義好的操作指令,而是支援使用者創建他們自 己想要的任何複雜的程式操作。開發人員可以使用以各種語言(如 JavaScript 和 Python) 為基礎編程語言創建在 EVM 上運行的應用程式。. 2.2.2.1. Solidity. Solidity 是一種智能合約高級語言,運行在 Ethereum 虛擬機的(EVM)之上。它的語法 接近於 Javascript,是一種物件導向的語言,參考圖 2.4。. 圖 2.4 Solidity 程式語言範例,本圖取自【24】. 2.2.3. Decentralized Application. Decentralized Application 簡稱為 DApp,是透過前端介面加上智能合約組合而成的應用程 式,跟以往的應用程式使用上並沒有太大的不同,而此應用程式執行的環境則是基於以 太坊區塊鏈的環境上。 DApp 的後端程式碼在分散的對等網路上運行,與後端程式碼在集中式服務器上運行的 應用程序形成對比。DApp 可以使用任何語言編寫前端程式碼和用戶界面,讓其可以調 8.
(24) 用後端。. 2.2.4. Smart Contract. Smart Contract 也稱之為智能合約,是 Ethereum 所引入最重要的概念。在比特幣區塊鏈 中,所有的帳戶地址都視為一個用戶,用戶的概念其實是指一對公鑰和私鑰。但在 Ethereum 中,除了由一組密鑰對所擁有的帳戶地址之外,還有一種由「程式碼」所擁 有的地址,即智能合約,參考圖 2.5。智能合約需要經由用戶開發以及部署,其本質是 一段程式碼,在部署到區塊鏈上之後便無法修改,智能合約正如普通帳戶一樣也擁有一 個錢包地址,每當這個地址收到交易時,所關聯的程式碼便會被執行,這些代碼只能以 區塊鏈作為輸入和輸出,因此,計算是可重複的,實際上計算的結果並不需要被存儲到 區塊鏈中,因為隨時可以重新進行計算,並且可以調用其它智能合約中的函數。其它智 能合約的程式碼和資料同樣存在於區塊鏈上,在執行過程中可以創建新的交易,而這些 交易可能會去執行其它的智能合約。. 圖 2.5 Smart Contract,本圖取自【4】. 2.3. Message Oriented Middleware. 由於科技與技術持續的演變,軟體系統必頇能夠因應演變的趨勢。合併、新增服務或擴 充可用的服務,通常需要重構軟體系統,在這種情況下,軟體系統需要整合新的元件或 9.
(25) 盡可能有效地擴充既有元件。針對整合不同性質的元件最常用的方法是提供一個層級, 使其可以無視差異進行通訊。 分散於不同網路節點的應用程式會使用應用程式介面進行通訊,而不用考量執行其它應 用程式的作業環境細節,也不用考量將其連線到這些應用程式的服務。此外,藉由提供 管理介面,這種新型的虛擬互連應用程式系統非常可靠安全,其效能可以測量和調校, 還能在不遺失功能的情況下進行延展。 訊息導向中介軟體是利用訊息傳送提供者協調訊息傳送作業。MOM 系統的基本元素為 用戶端、訊息和 MOM 提供者 (包含 API 和管理工具)。使用 MOM 系統時,用戶端發 出 API 呼叫將訊息傳送至提供者管理的伺服器,參考圖 2.6。用戶端可在傳送訊息後繼 續其它作業,提供者會保留訊息直到接收的用戶端接收到訊息為止。此訊息會耦合提供 者,以便有可能建立元件鬆散耦合的系統。這類系統即使在個別元件或連線失敗時,還 能夠可靠地繼續運作而不會當機。本研究需要透過不同的元件結合,將其整合成一套服 務伺服器,故使用訊息導向中介軟體的架構來實現。. 圖 2.6 Message Oriented Middleware,本圖取自【12】. 2.4. PostgreSQL. PostgreSQL 是以加州大學伯克利分校計算機系開發的 POSTGRES,為基礎的對象關係型 資料庫管理系統(ORDBMS) 。PostgreSQL 可以運行在所有主要操作系統上,包括 Linux, UNIX(AIX,BSD,HP-UX,SGI IRIX,macOS,Solaris,Tru64)和 Windows。PostgreSQL 10.
(26) 也符合 ACID,支持 foreign keys、joins、views、triggers 與 stored procedures。PostgreSQL 支援的資料類型包括 INTEGER、NUMERIC、BOOLEAN、CHAR、VARCHAR、DATE、INTERVAL 和 TIMESTAMP。PostgreSQL 也支持存儲二進制的大型資料,包括圖片、聲音與視頻。它 提供 C / C ++、Java、.Net、Perl、Python、Ruby、ODBC 等原生編程接口。. 2.5. Elasticsearch. Elasticsearch 是一個 Open Source 的搜尋專案,架構於 Apache Lucene 之上。此專案由 Shay Banon 於 2010 年 2 月啟動,使用 Apache 2.0 協定。 Elasticsearch 是一個高可靠、可擴展和高容錯的開源搜索和分析引擎,它允許存儲、搜 尋和分析大量的資料,而且整個過程非常的即時。它通常被用作底層引擎和技術,為複 雜的搜索功能和要求提供服務。 Elasticsearch 的特性如下: (1) 簡單透明與功能 API 化:Elasticsearch 並不是一個黑盒子。透過監控和管理的 API 可以完全了解和控制 Elasticsearch。 (2) 透過分片提高分佈性:同一個索引分成多個分片(sharding) ,透過分而治之的方式 來提升處理效率。 (3) 彈性與高可用性:提供備份(replica)機制,一個分片可以設置多個備份,使得某 台服務器當機的情況下,Elasticsearch 集群仍舊可以照常運行,並會把由於服務器 當機的備份恢復到其它可用節點上。. 2.6. Docker. Docker 最初是 dotCloud 公司內部的一個業餘專案透過 Go 語言實作,誕生於 2013 年。 Docker 是一種新型態的虛擬化方式,讓應用程式部署在軟體容器下的工作可以自動化進 行,藉此在 Linux 作業系統上,提供一個額外的軟體抽象層,以及作業系統層虛擬化的 自動管理機制,參考圖 2.7。 11.
(27) 圖 2.7 Docker Engine,本圖取自【18】. 2.7. Swagger. Swagger 是一個簡單但功能強大的 API 表達工具,它幾乎支援所有的現代編程語言。透 過使用 Swagger 生成 API,可以得到產生 Swagger UI,一套非常方便的 API 介面,可以直 接於介面上調用生成的 API 接口,也可以透過介面畫的方式顯示設定好的傳入範例格式 以及回傳格式範例。. 2.7.1. Open API 規範. OpenAPI 規範是 Linux 基金會的一個項目,詴圖通過定義一種用來描述 API 格式或 API 定義的語言,來規範 RESTful 服務的開發過程。OpenAPI 規範幫助我們描述一個 API 的基 本信息,譬如: (1) 有關該 API 的描述。 (2) 可用路徑或資源。 (3) 在每個路徑上的可用操作。 12.
(28) (4) 每個操作的 Input / Ouput 格式。. 圖 2.8 API 概念圖,本圖取自【10】. Swagger 也支援 Open API 的規範,透過 Open API 的規範,可以協助 API 定義語言能夠幫 助你更簡單、方便的表達 API,尤其是在 API 的設計階段。 依循 Open API 規範後 API 文檔可以作為: (1) 需求和系統特性描述的根據。 (2) 基礎的前後台查詢與 API 自我測詴。 (3) 可以自動生成部分或者全部代碼。 (4) 可以作為開放平台開發者手冊。. 2.8. BlockApps. BlockApps 是以太坊區塊鏈開發解決方案的供應商與開發商,BlockApps 是一個具有 RESTful API、瀏覽器和開發人員工具的私有以太坊區塊鏈軟體服務,使用的版本是 v1.2.2。 客戶端是使用 Haskell 編寫而成,提供了一個標準 RESTful API 與高度可擴展性的功能, 並且與以太坊區塊鏈兼容的區塊鏈服務。BlockApps 替建構和部署以太坊區塊鏈應用程 序提供了一個開發平台,並且於 Microsoft Azure 上提供了名為 BlockApps STRATO 的映像 檔,可以快速部署和提供 RESTful API,使開發人員能夠更快地建構、測詴和部署智能合 13.
(29) 約與 DApp,支援功能參考圖 2.9,介面參考 2.10。. 圖 2.9 BlockApps STRATO,本圖取自【9】. 圖 2.10 BlockApps 介面,本圖取自【9】. 2.8.1. BlockApps STRATO Architecture. BlockApps 的框架組成分成幾個部分,API Server、Message Queue、Persistence Layer 與 14.
(30) Ethereum 核心,參考 2.11。. 圖 2.11 BlockApps 架構圖,本圖取自【9】. 根據圖 2.11,Web Client 的資料都會經過 BlockApps API Server 處理後再儲存到 PostgreSQL 資料庫中,並且透過 Message Queue 將資料傳送到 Ethereum 區塊鏈的 LevelDB 中或者從 LevelDB 讀取出來。. 2.8.1.1. API Server. API 伺服器主要的作用在於接收所有從 Web Client 送過來的資料,並將資料透過邏輯運 算處理後再將資料寫入資料庫中,或者傳送至 Message Queue 內,等待後續的處理。. 2.8.1.2. Message Queue. 訊息佇列的部分,則是設計將傳送過來的訊息進行保留,並且派發至不同的邏輯程式裡 面進行處理。. 2.8.1.3. Persistence Layer 15.
(31) 持久儲存層的功用在於將傳送至 Ethereum 的資料進行儲存,方便快速查詢並建立關聯 性,區塊鏈的儲存模式屬於 Key-Value 的形式,而關聯式資料庫則可以提升多重條件搜 尋的能力,並且可以減少對 Ethereum 呼叫的次數。. 2.9. Etherscan. Etherscan 是一套提供 Ethereum 搜尋與分析的平台,也是一個去中心化的智能合約查詢 平台,介面如圖 2.13。 Etherscan 提供主要搜尋功能如下: (1) Address:透過以太坊地址搜尋此地址於此區塊上的餘額資訊或者交易紀錄。 (2) TxHash:透過交易雜湊值搜尋交易細節資料。 (3) Block:透過搜尋以太坊區塊鏈上面的區塊編號或是區塊雜湊,顯示區塊上的資訊。. 第三章. 區塊鏈中介元件軟體設計探討. Ethereum 在操作或是開發區塊鏈服務時需要先成為 Ethereum 的節點,要成為節點則需 要安裝 go-ethereum (Golang 語言撰寫)或 Parity (Rust 語言撰寫)來連接至 Ethereum 網路。 由於 Ethereum 的安裝設定非常複雜,加上目前去中心化的概念尚未普及等因素,學習 門檻相對較高 。因此,本研究提出了一個基於 Ethereum 上的中介軟體, 稱之為 BlockChainBox。用於連接 web3 與 go-ethereum,以解決使用者在開發區塊鏈服務時會碰 到的困難與障礙,透過此中介軟體來協助開發人員連接到 Ethereum。 BlockChainBox 將所有功能與操作封裝成 RESTful 的 API 框架,讓所有開發人員只需要有 最基本的 Client-Server 概念就可以將此中介軟體視為包裝過的 Ethereum 後端來進行開發。 此中介軟體也會提供 Ethereum 上的資料儲存與查詢功能,透過 API 呼叫的方式可以非 常容易的查看所有 Ethereum 上的公開資料。 16.
(32) 本研究所提出的 BlockChainBox 與其它中介軟體不同之處在於提供了智能合約的管理, 一般中介元件軟體並不會協助管理智能合約程式碼與智能合約的相關資訊。因此,當開 發人員需要使用智能合約內的任何方法時,就需要特別將智能合約的相關定義寫入區塊 鏈的服務內,才可以讓區塊鏈服務知道該智能合約的方法如何呼叫,這樣一來在區塊鏈 服務開發上需要做許多不同的處理與設計,故本研究所提出之中介軟體會將這些重要資 訊儲存於該軟體的資料庫中,方便開發人員隨時查驗。 本研究所提出之中介元件軟體透過 Webhook 的方式將交易完成或事件資訊,透過 call back 的方式將資訊傳輸到對應的伺服器內。Ethereum 是一個封閉的環境,而這個封閉 的環境並不會將資訊傳遞到外部,開發人員需要自己定時去詢問 Ethereum 來判斷是否 交易完成或者事件已發生,因此,本研究使用 Webhook 的原因在於減少頻繁的詢問 Ethereum 來判斷事件與交易是否已經完成,外部呼叫行為可以透過本研究所提出的 BlockChainBox 來達成,進而提升區塊鏈服務的效能並減少 Ethereum 的 I/O 次數。. 圖 3.1 BlockChainBox Middleware 概念圖. 3.1. BlockChainBox 架構設計. 本研究所設計的 BlockChainBox 區塊鏈中介軟體,主要用於連接 web3 與 go-ethereum, 並將其功能封裝成各個不同的 API 提供服務,透過此 BlockChainBox 的協助,將複雜的 操作流程封裝成各別的 API 接口,就軟體框架設計的概念來說,需要歸納頇解決下列幾 點問題: 17.
(33) (1) 連線至區塊鏈網路。 (2) 開發人員 Ethereum 地址管理。 (3) 智能合約部署、管理與相關資訊的保存。 (4) 管理區塊鏈智能合約與交易之間的關聯性資訊。 (5) 區塊鏈交易的失敗處理。 (6) 區塊鏈的非即時處理導致外部頻繁呼叫 Ethereum 的問題。. 3.1.1. 連線至區塊鏈網路. 想要加入區塊鏈網路的第一件事情就是如何連線至區塊鏈網路上,由於區塊鏈是一種分 散式系統,故每個節點都應該是獨立存在,所以會需要在機器上裝載 Ethereum 的核心 軟體,如:go-ethereum,來參與並且連到 Ethereum 網路上,並且透過 go-ethereum 創 建屬於自己的 Ethereum 地址,包含公鑰與私鑰來進行交易。而上述過程對於一般非開 發人員的使用者是非常困難的一件事情,故本研究提出透過系統化設計將上述功能封裝 成各種方法,並且將這些方法部署到伺服器上提供 API 的接口,透過使用伺服器上的 API 操作也等同於對 Ethereum 節點進行操作。. 3.1.2. 開發人員 Ethereum 地址管理. Ethereum 區塊鏈開發人員需要自己先透過 go-ethereum 創建地址的功能先創建出屬於自 己專屬的 Ethereum 地址,然後牢記自己當初設定的地址密碼與產生出來的私鑰,並且 自行備份到不同的地方。創建地址的功能本質上與一般會員管理系統創建帳號的功能無 異,在會員管理系統中使用者需要透過設定一組常用的帳號名稱,如:Email,並且針對 帳號設定一組屬於自己的密碼,而伺服器端會協助將這些資料儲存到資料庫中,並透過 備份的方式將資料儲存在許多地方,故本研究將 go-ethereum 的功能進行封裝,將其套 用會員管理系統的架構設計出針對 Ethereum 區塊鏈的帳號管理系統。. 18.
(34) 3.1.3. 智能合約部署與管理. 智能合約的開發過程,需要先透過 Ethereum 所提供的語言,如:Solidity,來撰寫智能 合約所需要的程式碼,而 Solidity 是一種編譯式的語言,所以需要額外安裝編譯器來將 程式碼的編譯為 bytecode,而 bytecode 則是主要儲存到 Ethereum 區塊中的訊息。在開 發智能合約的過程中開發人員需要自己保存智能合約的相關資訊,並且紀錄所執行過智 能合約的位置,此外還要將智能合約編譯出來的 ABI 封裝成為可呼叫的函式,這些資訊 都需要自行記錄在區塊鏈外,針對函式的封裝與程式碼管理上會對開發人員造成某種程 度上的困擾,故本研究提出透過建立區塊鏈外的資料庫,來儲存以及管理智能合約的程 式碼與函式結構,並且將函式封裝成 API 的參數進行傳遞,如此一來可以省略函式封裝 的過程並且提供更簡易的方法管理智能合約。. 3.1.4. 管理區塊鏈智能合約與交易之間的關聯性資訊. 目前針對區塊鏈智能合約的資料查詢僅能取得智能合約的 bytecode 與機器碼,但是無法 從智能合約中取得原本部署的程式碼,因為無法擁有原始智能合約的程式碼,所以也無 法從智能合約程式碼中取得其 ABI,如此一來就算可以透過智能合約的地址來取得所有 針對該智能合約所進行的交易,也無法輕易的知道每一筆交易是在針對哪個智能合約的 方法進行調用,甚至判斷其交易執行期間是否有產生任何的事件,這邊對於開發人員來 說目前唯一的解決方法就是架設 Ethereum 核心程式成為 Ethereum 網路的節點之一,透 過開發監聽程式來針對部署過後的程式碼進行資料搜集,本研究將透過開發交易監聽與 事件監聽模組來協助開發者解決此部分開發上的困擾,並且透過 Elasticsearch 將這些資 料儲存到資料庫中方便使用 API 調用的方式查詢。. 3.1.5. 區塊鏈交易的失敗處理. 區塊鏈的任何交易都有可能因為各種原因導致失敗,如:gas 消耗光但是程式尚未跑完、 交易參數輸入錯誤,一般軟體開發流程中,會在失敗錯誤的時候增加例外判斷,或者提 19.
(35) 供一些 retry 的機制,來協助交易重送,而區塊鏈至目前為止並沒有任何軟體或者套件 能夠協助在交易過程中提供一套完善的失敗處理機制,本研究提出設計交易排程模組, 來協助失敗交易可以定期自動重送的機制。. 3.1.6. 區塊鏈的非即時處理導致外部頻繁呼叫 Ethereum 的問題. 區塊鏈是一個封閉性的環境,需要取得區塊鏈上的資訊必頇透過外部的呼叫,並且區塊 鏈執行交易後並且寫到區塊上是需要透過時間上的處理,此部分是非即時的資訊,由於 外部應用會有資訊的需求,所以一般來說都會透過 Long Polling 的方式針對區塊鏈上的 交易處理結果進行頻繁的詢問,這些動作對於機器來說是一種負擔,當交易量大的時候 則需要開非常多的執行緒來監聽每筆交易的結果,會使系統負擔增大,故本研究提出使 用 Webhook 透過 Call back 的方式將交易結果的資料主動推送到接收端,以降低系統負 擔。. 本研究針對綜合以上問題設計一套區塊鏈中介軟體,並將其功能封裝成各個不同的模組 並且透過 API 提供服務,其架構如圖 3.2 所示:. 圖 3.2 BlockChainBox 架構圖 20.
(36) (1) API Gateway 著重於將封裝後的方法提供一個對外的接口,可以允許從外部將資料 傳輸到中介軟體內部進行處理,並且分派到對應的邏輯處理程式。 (2) Account Manager 則是透過帳號管理功能設計,將資料儲存到 PostgreSQL 資料庫中, 來限制 BlockChainBox 開發人員允許操作哪些功能,並且只能針對自己所擁有的資 源來操作,而 Account Manager 也會透過創建帳號的同時來協助創建 Ethereum 上對 應的 Address。 (3) Blockchain Explorer 負責定期將資料搜集存到 ElasticSearch 資料庫中,方便直接查詢 而不需要再透過 go-ethereum 到區塊鏈上進行搜尋,減少資源與時間的消耗。 (4) 本研究中模組與模組間的 Message Oriented Middleware 則是使用 Amazon 的 SQS, 透過 Amazon 提供的高穩定性與高度擴展性來協助。. 3.2. BlockChainBox 模組化設計 本研究之 BlockChainBox 透過實現 Message Oriented Middleware 的方式,採取模組 化的設計,將功能與功能間拆成數個模組,目的是降低功能與功能間的耦合性,提 升未來在開發上的擴充性與模組的可替換性,本系統共可歸納成以下模組,參考圖 3.3:. (1) Account Management:開發人員對於帳號與 Ethereum 地址的權限控管,故設計 Account Management 模組來負責使用者權限的控管。 (2) Ethereum Explorer:使用者需要簡易的獲得 Ethereum 的各種資訊,故設計 Ethereum Explorer 來負責區塊鏈上的資料搜尋。 (3) Contract Handler:智能合約程式碼與 ABI 的保存, Contract Handler 會將智能合約 的資料保存在資料庫中,並且建立與 Contract Function,Contract Event 的關聯性。 (4) Transaction Handler / Tracker:此模組會處理 Ethereum 上交易資訊的儲存與交易失 敗的控管。 21.
(37) (5) Event Handler:此模組著重於處理 Ethereum 上事件資訊的儲存。 (6) Ethereum Gateway:此模組負責透過調用的方式操作 Ethereum 上的功能,Ethereum Gateway 負責將透過 RPC 對於 Ethereum 的操作封裝成對外 API。 (7) Webhook Support:此模組負責透過 Webhook 此種主動呼叫外部伺服器的方式,來 解決一般伺服器端需要被外部頻繁呼叫的問題。. 圖 3.3 BlockChainBox 模組設計圖. 3.2.1. Message Oriented Middleware 實作. 本研究透過 Message Oriented Middleware 的設計模式,將 BlockChainBox 內的功能模組 化,透過訊息交換的方式讓模組與模組之間互相溝通,可以有效降低整個系統架構的耦 合性,方便擴充與維護,參考圖 3.5。. 22.
(38) 圖 3.4 BlockChainBox Message Oriented Middleware. BlockChainBox 中的各個模組與模組之間的訊息傳遞,通過實作不同的 Queue 來進行訊 息的溝通,詳述如下: (1) Contract Queue:當系統收到需要部署合約的時候,系統會將智能合約的程式碼進 行編譯,確認無誤後才將完整的資訊打包送到 Contract Queue 內,由 Contract Handler 來負責將資料送到到區塊鏈上。 (2) Transaction Queue:當系統收到需要針對智能合約內的方法進行調用的 transaction, 系統會將 transaction 送到 Transaction Queue 內,由 Transaction Handler 負責將資料 送到區塊鏈上,並且獲得對應的 Transaction Hash。 (3) Transaction Receipt Queue:當系統得知有 transaction 發生並且得到 Transaction Hash 後,系統會將 Transaction Hash 的值送到 Transaction Receipt Queue 內,由 Transaction Handler 負責監聽 Transaction Hash 是否已經被區塊鏈中的節點所寫到區塊上。 (4) Event Queue:當系統得知有 transaction 發生並且該智能合約內的方法有包含 event, 系統會將 Transaction Hash 的值送到 Event Queue 內,由 Event Handler 負責監聽 Transaction Hash 是否已經被寫入到區塊上且廣播 event 的資訊。 23.
(39) (5) Webhook Queue:當系統在 Contract、Transaction、Event 這些功能內有設定 Webhook 的 Callback URL 系統會將 URL 與資料傳到 Webhook Queue 內,由 Webhook Handler 將資訊傳送至對應的 URL。. 3.2.2. Docker 導入. 本研究導入 Docker 來協助部署,利用每個 Docker Container 都擁有屬於自己獨立環境的 特性,透過 Docker 協助部署多個 Container 來架設 Ethereum 網路,使架設私有鏈與聯 盟鏈很容易實現分散式節點的功能。透過 Docker 的主要功能,本研究將核心程式封裝 成為一個一個的 Docker Container 將其部署於數台機器上,透過 Router 指向不同的節點。 使用 Docker 的另外一個優勢是很容易動態的增減 Ethereum 網路中 Docker Container 的 節點數量,參考圖 3.5。. 圖 3.5 BlockChainBox Docker Containers 示意圖. 3.2.3. Account Management. 在任何一套封閉式系統上,都必頇擁有帳號權限管理功能來對所有帳號的使用範圍做某 種程度上的限制,作為一個中介軟體也必頇要擁有一個的帳號權限管理功能來識別不同 的使用者能夠操作哪些功能與合約。 使用者在本研究所提出的 BlockChainBox 上會擁有一個專屬於使用者的帳號,以及 Ethereum 上的特定地址,讓此使用者帳號持有人也可以對自行對 Ethereum 進行交易。 24.
(40) 圖 3.6 使用者帳戶與以太坊地址資料庫關聯圖. 在資料庫的設計上採取一對多的概念,一個帳號允許擁有多個 Ethereum 地址,也允許 同一個人擁有多個 Ethereum 地址,並且可以透過這些地址進行交易與部署智能合約於 Ethereum 區塊鏈上。. 3.2.3.1. 帳號管理. 帳號管理會透過 Access Token 來區分各個使用者,而此 Access Token 稱之為存取權杖。 有鑒於帳號管理的設計,客戶端對於本研究之 BlockChainBox 的操作模式都是使用 API 來進行調用,在調用時需要各別識別各個使用者的身份,因此,本系統採用了存取權杖 的設計,提供遠端訪問的區塊鏈服務有各自的存取權杖,可以方便系統記錄 API 調用的 使用量以及針對帳戶的存取權杖進行控管。 存取權杖會透過密碼學 SHA3 來產生,使用帳號加上特定字串與任意隨機數來產生對應 的存取權杖,程式碼如 3.1 所示,系統也會產生對應的地址密碼給使用者,本系統也允 許將該地址的私鑰進行匯出自己保存。. 程式碼 3.1 Access Token 產生方式. 3.2.4. Ethereum Gateway 25.
(41) Ethereum 區塊鏈內所有功能都需要透過 web3 連接到 go-ethereum 來進行調用,包含智 能合約的部署、Block 資料的查詢、Ethereum 地址與地址間的交易及查詢等,這些主要 功能都需要有對應的 API 接口來負責操作才能對外提供服務,各個 API 再依據不同的功 能接受不同的參數,故設計 Ethereum Gateway 來將這些功能封裝在 API 內,以方便所有 使用者調用,參考圖 3.7。. 圖 3.7 API Gateway 架構圖. 3.2.4.1. Transaction. 以太坊對鏈上所有的行為操作都叫做 Transaction,而每一筆 Transaction 都會有對應的 Transaction Hash,用以識別與追蹤該交易的狀態及資料。 本研究所提出之 BlockChainBox 會協助紀錄所有交易的資訊並且存在資料庫中,記錄在 資料庫的內容包含 Transaction Hash、以及交易狀態、交易發生的時間、以及被 Ethereum 26.
(42) 網路上的節點所寫入到區塊上的時間,不但可以判斷該交易成功或者失敗,甚至定義失 敗時需要針對該筆交易進行哪種處理。. 圖 3.8 TransactionData Table Schema. 3.2.5. Contract Handler. 以太坊上最特別的創新就是智能合約的功能,能夠將程式碼透過傳送 Transaction 的方式 部署在以太坊的區塊鏈上面,並且外部呼叫的時候就自動執行該程式碼。而智能合約的 執行也可視為一種 Transaction,需要透過監聽以太坊區塊鏈上的交易狀態來判斷合約是 否有部署完成。此外在部署合約之前也必需要先行將程式碼 Compile 判斷是否有撰寫錯 誤,如果無誤後再將其轉換成機器碼(bytecode)並且打包在交易的參數中,才可以將 合約程式碼部署到以太坊區塊鏈上。. 27.
(43) 圖 3.9 Contract Table Schema. Contract Handler 主要在於協助將智能合約的名稱(name)、智能合約的原始程式碼 (sourceCode) 、編譯出來的 bytecode(byteCode) 、智能合約的 ABI(abi) 、撰寫智能合 約所使用的程式語言(language)以及智能合約存在於區塊鏈上面的位置(address)記 錄下來,參考圖 3.9。 上述這些資料對於智能合約來說非常重要,固本研究提出將資料放到區塊鏈以外的資料 庫中協助保存,而使用者只需要透過調用 API 即可獲得智能合約之相關資訊。. 28.
(44) 圖 3.10 Contract Handler Flow. Contract Handler 的運作如圖 3.10,過程如下: (1) Clinet 傳送智能合約資料到本系統。 (2) 透過 API Gateway 將資料導向對應的 Controller。 (3) Controller 會先將資料內的智能合約程式碼先行編譯,之後儲存到 RDBMS 的 Contract、 ContractFunction 與 ContractEvent 這三個 Table 內,並且發送 Message 至 Contract Queue。 (4) 透過 Contract Consumer 將 Contract Queue 內的資料擷取出來並且透過 Web3 寫入 Ethereum 區塊鏈上,並且等待 Web3 將資料寫入 Ethereum 區塊鏈內,當寫入完成 後,更新合約位置至 RDBMS 至 Contract Table 內,並且發送 Message 至 Webhook Queue。 (5) 透過 Webhook Consumer 將 Webhook Queue 的資料讀取出來,並且向 Client 所指定 29.
(45) 的 URL 進行資料傳遞。. 3.2.5.1. Contract Function. 一份合約內至少會有一個以上的 Contract Function 可以呼叫,而本研究所提出的 BlockChainBox 會解析智能合約的程式碼,將所有 Contract Function 都分別存入資料庫中, 與原本的合約建立關聯性,並且提供 API 調用以及查詢此兩項功能。. 圖 3.11 Contract Function 關聯圖. 一份智能合約的程式碼內,會包含一個以上的 Contract Function,如圖 3.11,本系統會 將其拆解之後儲存到資料庫中,方便未來呼叫使用,並且對於每一次外部調用也會將其 完整資料記錄下來,以便隨時驗證與查詢。. 3.2.5.2. Contract Event. 一份合約內可以能包含零個以上的 Contract Event,但 Contract Event 需要被包含在 Contract Function 之內, 當合約部署到區塊鏈前 BlockChainBox 會判斷解析後的合約程 式碼,是否有包含任何 Contract Event,再與原本的合約與 Contract Function 建立關聯性 存入資料庫中,並且提供 API 查詢的功能。 30.
(46) 圖 3.12 Contract Event 關聯圖. 一 份 智 能 合 約 的 程 式 碼 內 會 包 含 零 個 以 上 的 Contract Event , 如 圖 3.12 所 示 。 BlockChainBox 會將其分析之後建立關聯性並且儲存到資料庫中,並且對於每一次調用的 結果也會將其完整資料記錄下來,以便隨時驗證與查詢。. 3.2.6. Transaction Handler. 當使用者透過 API 調用 Contract Function 時,Transaction Handler 會判斷該 Contract Function 的參數是否符合該 Contract Function 可調用的參數數量,之後再透過資料庫找 出該 Contract Function 的 ABI 將資料傳送到以太坊區塊鏈上。當送至以太坊區塊鏈上之 後,會產生對應的 Transaction Hash,而 BlockChainBox 則會針對該 Transaction Hash 進行 監聽,直到該 Transaction Hash 真正寫入到區塊中再判斷 Transaction Receipt 是否有正確 完成或者是中間有發生錯誤,Transaction Handler 會將資訊記錄到資料庫中。. 31.
(47) 圖 3.13 Transaction Handler Flow. Transaction Handler 的運作如圖 3.13,過程如下: (1) Clinet 傳送 Transaction 資料到 API Gateway。 (2) 透過 API Gateway 將資料導向對應的 Controller。 (3) Controller 執行將 Transaction 資料儲存到 RDBMS 的 TransactionData Table,並且發送 Message 至 Transaction Consumer (4) 透過 Transaction Consumer 將 Transcation Queue 內的資料擷取出來並且透過 Web3 寫入 Ethereum 區塊鏈上,並且發送包含 Transaction Hash 的 Message 至 Transaction Receipt Consumer。 (5) 透過 Transaction Receipt Consumer 將 Transaction Receipt Queue 內的資料擷取出來並 且透過輪詢的方式判斷該筆 Trasaction 是否已經被寫至 Ethereum 區塊鏈內,寫入後 32.
(48) 將狀態更新至 RDBMS 的 TransactionData Table,並且發送 Message 至 Webhook Queue。 (6) 透過 Webhook Consumer 將 Webhook Queue 的資料讀取出來,並且向 Client 所指定 的 URL 進行資料傳遞。. 3.2.7. Event Handler. 當使用者透過 API 調用 Contract Function 時,系統會判斷 Contract Function 內是否有任 何關聯的 Event 存在,若有,則會透過 Event Handler 監聽發射出來的 Contract Event 並 且將資料儲存到資料庫中。 Event Handler 的設計方法,是將有調用到與 Contract Event 相關聯的 Contract Function 時, 會傳送一則訊息到 Message Queue 內,並且等待背景程式將該訊息接收並且監聽以太坊 上該 Transaction Hash 是否有被記錄到區塊中,當 Transaction Hash 正確完成並且記錄到 區塊中,則會在發送一則訊息到 Message Queue 內,並且等待另外一個背景程式將該訊 息接收並且針對該區塊進行資料讀取,取出所有該區塊上該 Contract Function 的 Contract Event 並且針對該 Transaction Hash 內的 Contract Event 做記錄。. 33.
(49) 圖 3.14 Event Handler Flow. Event Handler 的運作如圖 3.14,過程如下: (1) Clinet 傳送 Transactoin 資料到本系統。 (2) 透過 API Gateway 將資料導向對應的 Controller。 (3) Controller 執行將資料儲存到 RDBMS 的 TransactionData Table,並且發送 Message 至 Transaction Queue。 (4) 透過 Transaction Consumer 將 Transcation Queue 內的資料擷取出來並且透過 Web3 寫入 Ethereum 區塊鏈上,並且發送 Message 至 Transaction Receipt Queue。 (5) 透過 Transaction Receipt Consumer 將 Transaction Receipt Queue 內的資料擷取出來並 且透過輪詢的方式判斷該筆 Trasaction 是否已經被寫至 Ethereum 區塊鏈內,寫入後 將狀態更新至 RDBMS 的 TransactionData Table,並且發送 Event Message 至 Event 34.
(50) Queue。 (6) 透過 Event Consumer 將 Event Queue 的資料讀取出來,並且直接對 Ethereum 區塊 鏈讀取 Event 的資料,並且存入 RDBMS 的 EventData Table 內,並且發送 Webhook Message 至 Webhook Queue。 (7) 透過 Webhook Consumer 將 Webhook Queue 的資料讀取出來,並且向 Client 所指定 的 URL 進行資料傳遞。. 圖 3.15 Event Table Schema. 3.2.8. Webhook Support. Webhook 是一種通過自定義回調來增強或改變網頁或 Web 應用程序的行為的方法,本 研究提供 Webhook 支援來達成主動通知 Client 端的設計。 本系統使用 Webhook 的應用在於透過交易與事件的觸發,會對該 API 配置的 Webhook URL 發出 HTTP 請求,採取的行動是將交易或事件的結果整個打包成 JSON 格式再傳送出 去。由於 Webhook 使用的是 HTTP/HTTPS 並且遵照 RESTful,因此,可以將資料傳輸到 35.
(51) Web 服務中,而 Client 端無需添加新的基礎架構。. 圖 3.16 Webhook Handler Flow. Client 端傳送訊息過來,如果是調用智能合約內的方法,則系統會針對 Contract、 ContractEvent 與 ContractFunction 這三個 Table 裡面所關聯到 WebhookData Table 內所設 定的 URL 去發送訊息,而訊息來源則是透過 Web3 從 Ethereum 內部的區塊廣播出來的 訊息做發送,資料庫關聯參考圖 3.17。. 36.
(52) 圖 3.17 WebhookData Table Schema. 3.2.9. Ethereum Explorer. 以太坊區塊鏈上面的資料都是需要透過中間層,例如:web3.js 來進行調用,才可以取 得每個區塊中所記錄的資料,此功能的設計在於透過儲存在區塊鏈外部系統,可以不需 要每次都透過 web3.js 進行調用,本系統也將透過包裝過的 API 呼叫外部資料庫,減少 查詢的條件,針對各種查詢模式分類,讓使用者可以針對想要的訊息對外部資料庫進行 查詢。 37.
(53) 3.2.9.1. Elasticsearch. 本系統使用 Elasticsearch 將蒐集到的區塊鏈資料進行儲存,主要是針對區塊鏈的不可竄 改性,區塊鏈上的每個區塊經由廣播後資料及固定,故不需要頻繁的更改 Elasticsearch 內的資料內容,本系統使用 Elastcisearch 的搜尋功能將區塊中的資料方便任何針對區塊 鏈上的資料進行查詢。 Elasticsearch 使用 Java 開發作為其核心來實現所有索引和搜索的功能,但是它的目的是 通過簡單的 RESTful API 來降低操作上的複雜性,從而讓全文搜索變得簡單。. 3.2.9.2. Explorer Service. 本研究所設計的 Ethereum Explorer 模組是將更豐富的資訊提供給開發者,Explorer 的內 容資訊與直接透過 Web3.js 搜尋 Ethereum 網路上的資料並無差異,Ethereum 網路上的 資料亦可以透過 Etherscan 等第三方軟體查詢,故本研究所提出的設計是利用 Elasticsearch 本身已實作的優化查詢功能來提升效能,並且可以透過不同的過濾方式來 搜尋,以加強搜尋功能。 本研究之 BlockChainBox 與目前針對以太坊提供服務的 Explorer Service 相比,如: etherscan.io,此第三方查詢需要透過該智能合約的開發人員將程式原始碼貢獻上去,才 能獲得該合約的 ABI 與完整合約資訊。 本研究使用中介軟體協助合約編譯及解析程式碼,將合約內所包含的所有 Function、 Event 擷取出來建立彼此之間的關聯性,之後才將其部署至 Ethereum 區塊鏈上。當合約 部署完成後中介軟體將紀錄合約位於 Ethereum 區塊鏈上的 address、合約部署時的 Transaction Hash、合約執行時所需要的 ABI、合約的 bytecode 等重要資訊於資料庫中, 方便查詢,透過本研究提供的 Ethereum Explorer 查詢合約的 address 可以獲得合約全方 位的資訊,參考圖 3.18。. 38.
(54) 圖 3.18 使用 BlockChainBox Explorer 搜尋 Contract. etherscan.io 目前提供的搜尋功能,透過 address 查詢後並沒有提供合約的原始碼、合約 的 ABI 等資訊,需要由程式開發者自行上傳,如圖 3.19。. 39.
(55) 圖 3.19 使用 etherscan.io 搜尋 Contract. Ethereum Explorer 提供的查詢包含五個功能,參考圖 3.20: (1) 透過 Block 搜尋:系統會將區塊資訊寫入至資料庫內,查詢部分提供 API 調用,會 將資料打包成 JSON 格式進行回傳。 (2) 透過 Address 搜尋:系統會將交易地址的每一筆交易資訊寫入資料庫中,查詢部分 提供 API 調用,會將資料打包成 JSON 格式進行回傳。 (3) 透過 Contract Address 搜尋:將所有透過此中介軟體部署的智能合約內容儲存至資 料庫中,建立 Contract Function 與 Contract Event 的關聯性,其內容完整包含第三方 軟體所缺乏的合約原始程式碼、合約的 ABI、合約執行部署時的 Transaction Hash, 查詢部分提供 API 調用,會將資料打包成 JSON 格式進行回傳。 40.
(56) (4) 透過 Transaction Hash 搜尋:系統會將所有交易雜湊都記錄至資料庫中,並且與地 址建立關聯性,查詢部分提供 API 調用,會將資料打包成 JSON 格式進行回傳。 (5) 透過 Event 搜尋 :本研究所提出之中介軟體會監聽部署在此套系統的合約所廣播出 來的 Contract Event,並且儲存至資料庫中,與合約建立關聯性,查詢部分提供 API 調用,會將資料打包成 JSON 格式進行回傳。. 圖 3.20 BlockChainBox Explorer Service 架構圖. 3.2.10 Swagger UI Swagger UI,如圖 3.21 所示,是一款針對 RESTful API 服務提供一個自我描述的方法並配 合一個有用的客戶端工具,讓 RESTful API 的使用者了解服務內容與調用它。 本系統使用此服務建構伺服器 RESTful API 介面,透過 Swagger UI 直接查看 RESTful API 的功能,並且直接調用來取得結果,此開發模式可以有效減少客戶端的模索與開發時 間。. 41.
(57) 圖 3.21 Swagger 介面圖. 3.2.11 Docker Support Docker 的優勢在於除了執行其中應用外,基本不消耗額外的系統資源,使得應用的效能 很高,同時系統資源消耗更少。 本系統透過 Docker Compose 將數個實體環境隔離,設計上依照不同的職責來劃分不同 的 Container,並且可以依照開發環境需求的不同來抽換不同的 Container。 本系統分為以下四個部分: (1) 以太坊區塊鏈:目前以太坊區塊鏈可以使用不同的 Container 支援不同的 network, 包含:Mainnet、Testnet、Private。 (2) 本研究所使用的應用程式:使用的開發語言為 JavaScript、框架為 Node.js。 (3) 資料庫:使用的資料庫為 PostgreSQL。 (4) 搜尋引擎:此部分使用 Elasticsearch。. 42.
(58) 第四章. 區塊鏈中介元件軟體使用探討. 本研究將以開發人員的角度切入,操作此系統以開發區塊鏈的應用服務,進而探討本中 介軟體的設計,證明對於一個熟悉 RESTful API 操作的程式設計師來說,是很容易使用本 中介軟體來輔助開發。 本章將依循 Account Management、Ethereum Gateway、Contract Handler、Transaction Handler、Event Handler、Webhook 及 Ethereum Explorer 的順序來進行說明。. 4.1. Account Management. 本系統將提供給不同的開發者使用,因此,會透過 Account Management 的設計針對每 一個使用者創建一個自己的帳號,並且該帳號底下會有自己專屬的 Ethereum 地址來操 作。 使用本系統調用 Account Management 註冊使用者的方法如下,參考圖 4.1: (1) 使用 POST 方法調用 /account/create:當使用者需要創建一個帳戶,並且操作本系 統的時候,需要調用此 API 將帳號密碼傳到本系統中,即可創建個人帳戶。. 圖 4.1 Account Management API 43.
(59) 4.2. Ethereum Gateway. Ethereum 是一個封閉式的環境,目前所有對 Ethereum 的操作都需要透過 web3 來操作, 故本系統將 web3 的功能都封裝成 RESTful API 提供給外部使用者來調用。 使用本系統調用 Ethereum Gateway 的方法如下,參考圖 4.2: (1) 使用 GET 方法調用 /eth/compilers:這邊會回傳當前系統所支援以太坊智能合約的 程式語言。 (2) 使用 POST 方法調用 /eth/newAddress:當使用者需要在自己的帳戶中增加一個以太 坊地址,可以透過此 API 傳入自定義的密碼,綁定自有帳戶與以太坊地址。 (3) 使用 GET 方法調用 /eth/coinbase:回傳目前主要的以太坊帳戶地址。 (4) 使用 GET 方法調用 /eth/balance:可以透過此 API 查詢任意以太坊帳戶地址內的數 位貨幣餘額,單位為 ether。 (5) 使用 GET 方法調用 /eth/transactionReceipt:透過傳入交易的雜湊值來取得該筆 Transaction Hash 目前的狀態與資料,內容包含: (1) 。 (6) 使用 GET 方法調用 /eth/estimateGas:執行交易或是傳送訊息,該調用直接在本系 統的 VM 中執行,但並未將資料寫入以太坊區塊鏈中,等同於模擬執行,執行結束 後回傳使用的 Gas 量。 (7) 使用 GET 方法調用 /eth/gasPrice:讀取並回傳當前的 Gas 價格。 (8) 使用 GET 方法調用 /eth/blockNumber:讀取並回傳當前最後一個區塊的編號。 (9) 使用 GET 方法調用 /eth/hashRate:讀取並回傳該節點正在挖掘的每秒雜湊數。 (10) 使用 GET 方法調用 /eth/blockInfo:透過傳入區塊的編號或者是區塊的雜湊值,讀 取並回傳該區塊的資料。 (11) 使用 GET 方法調用 /eth/blockTransactionCount:透過傳入區塊的編號或者是區塊的 雜湊值,讀取並回傳該區塊上所包含的交易數量。 44.
(60) 圖 4.2 Ethereum Gateway API. 4.3. Contract Handler. Contract 的原始程式碼是非常需要被保存下來的資料,原因涉及呼叫合約內的任何 function 都需要原始程式碼所產生出的 ABI 來得知該 function 的方法名稱、參數數量及 型別,故本系統會將這些資訊儲存到外部資料庫,方便保存與查詢,並提供 RESTful API 給外部調用。 使用本系統調用 Contract 的方法如下,參考圖 4.2 與圖 4.3: (1) 使用 POST 方法調用 /eth/contracts:此 API 支援傳入智能合約的程式碼與 Webhook 的網址,協助使用者將合約部署至以太坊區塊鏈上,並且回傳部署完成的智能合約 等相關資訊,包含智能合約於資料庫中的鍵值、ABI、bytecode、智能合約地址、交 易雜湊、編譯智能合約所分拆出來的 Contract Function 與 Contract Event、智能合約 所消耗的 Gas 等重要資訊。 (2) 使用 GET 方法調用 /eth/contract:此 API 支援傳入智能合約於資料庫中的鍵值,來 45.
相關文件
二、本校於報名表中對於學生資料之蒐集,係為學生成績計算、資料整理及報 到作業等招生作業之必要程序,並作為後續資料統計及學生報到註冊作業
利用 Microsoft Access 資料庫管理軟體,在 PC Windows 作業系 統環境下,將給與的紙本或電子檔(如 excel
利用 Microsoft Access 資料庫管理軟體,在 PC Windows 作業系統環境 下,將給與的紙本或電子檔(如 excel
並以中科園區核准進駐事業單位中已建廠完成且投入實際生產的廠 商作為資料蒐集的基礎。 「行政院國家科學委員會」科學園區協調小組 公布資料指出,統計至 96 年 6
依個人資料保護法第八條規定,本會將會蒐集個人資料,要求輸
以下簡單介紹魔術三角形: 如圖 1, 若三角形每邊有 三個數且數字和都是定值, 稱為 3 階 (傳統) 魔術三角形; 如圖 2, 若每邊有三 個數且較大兩數和減最小數的差都是定值, 稱為
利用 Microsoft Access 資料庫管理軟體,在 PC Windows 作業系 統環境下,將給與的紙本或電子檔(如 excel
討論結束,整理腦圖。首先嘗試將資料歸類,然 後可以開始收窄範圍,定出文章中心,再按照重