一種面向Fabric區塊鏈應用軟件的體系結構演化算法

趙會群 張隆龍

摘? 要： 針對聯盟鏈Fabric中，orderer節點一旦發生異常，只能在下一個時間間隔繼續，而當前時間間隔浪費的問題，本文對Fabric體系結構進行了演化，提出了一種新的思路，使得orderer節點產生異常后，系統可以在當前間隔內正常工作，不必等到下一個時間間隔。最后通過實驗對算法在吞吐量、資源利用率等性能指標上進行了對比分析，表明了Fabric軟件軟件體系結構演化算法的有效性。

關鍵詞： 區塊鏈;Fabric聯盟鏈;體系結構演化;容錯機制

中圖分類號： TP311 ???文獻標識碼： A??? DOI：10.3969/j.issn.1003-6970.2020.07.001

本文著錄格式：趙會群，張隆龍. 一種面向Fabric區塊鏈應用軟件的體系結構演化算法[J]. 軟件，2020，41（07）：01-10+60

An Architecture Evolution Algorithm for Fabric Blockchain Application Software

ZHAO Hui-qun， ZHANG Long-long

（North China University of Technology， Information Institute， Beijing 100144， China）

【Abstract】： In order to solve this problem： at the alliance chain Fabric， if the orderer node has an exception， it can only continue at the next time interval and the current time interval is wasted， this paper proposes a new idea to evolve the fabric architecture， so that after the orderer node has an exception， the system can work normally in the current interval without waiting for the next time interval. Finally， the algorithm was compared and analyzed through experiments on performance indicators such as throughput and resource utilization， which showed the effectiveness of the evolutionary algorithm of the Fabric software architecture.

【Key words】： Blockchain; Fabric alliance chain; Architecture evolution; Fault tolerance mechanism

0? 引言

區塊鏈技術興起于2008年，化名為“中本聰”（Satoshi nakamoto）的學者發表了一篇奠基性論文《Bitcoin： a peer-to-peer electronic cash system》^[1]，具有去中心化、不可篡改和數據本地化存儲等特性。

區塊鏈技術的開源項目有很多，目前使用最廣泛的是超級賬本（Hyperledger）項目^[2]。該項目成立于2015年12月，由開源世界的旗艦組織Linux基金會牽頭成立。項目為透明、公開、去中心化的企業級分布式賬本技術提供開源參考實現，并推動區塊鏈和分布式賬本相關協議、規范和標準的發展^[3]。其中子項目Fabric最早由IBM和DAH發起，目標是作為區塊鏈的基礎核心平臺，定位是面向企業的分布式賬本平臺，創新地引入了權限管理支持，是首個面向聯盟鏈場景的開源項目^[4]。

Fabric是一個開源的企業級許可分布式賬本技術平臺，相比于傳統的公有鏈，有著更好的性能^[5]，其最重要的特點就是可插拔性。沒有任何一個區塊鏈平臺能夠滿足所有需求，但是Fabric 可以通過配置來盡可能的滿足多樣化需求。

底層由peer節點和orderer節點組成了P2P網絡，通過Google開源的RPC框架-gRPC進行交互，客戶端把用戶輸入的數據構建成交易提案，發送給背書節點（背書策略指定的peer節點），背書節點模擬執行交易后，將結果集返回給客戶端，客戶端根據結果集構建交易，發送給orderer節點，在orderer節點中，對于收到的交易，進行排序，打包生成塊后，返回給peer節點，peer節點驗證后，寫入本地帳本，并利用Gossip廣播協議同步數據。

中間使用通道技術（channel）進行隔離，每個通道都是一個獨立的網絡，擁有自己的賬本（ledger）。賬本的底層是數據庫，fabric中采用goleveldb，對賬本的操作，追根溯源，還是對數據庫的操作。賬本記載了一系列交易，完成交易依賴于共識算法，交易會觸發事件。交易是由SDK發起的，其底層是應用鏈碼（Application chaincode，簡稱ACC），除了ACC外，還有系統連碼（System chaincode，簡稱SCC），主要用來管理ACC，不管是ACC還是SCC，都是鏈碼（chaincode），都依賴于容器技術和狀態機（finite state machine，有限狀態機，簡稱FSM）技術。權限管理是獨立出來的，使用了PKI體系，由CA（Certificate Authority，即頒發數字證書的機構）節點負責頒發證書，底層是fabric封裝好的MSP（Membership Service Provider）服務。

Fabric向上層應用提供了gRPC API以及把API進行封裝的SDK， 應用可以通過SDK訪問賬本、處理交易、管理鏈碼、注冊事件、管理權限等多種資源。SDK的實現有多種，目前支持最完整的版本是Java和nodejs。整個框架的核心就是賬本，負責記錄框架上所有應用的信息，而應用通過SDK發起交易來向賬本記錄數據，交易執行的邏輯通過ACC來承載。

Fabric中的orderer節點負責對交易排序、打包成塊，依照共識算法在一個時間間隔內，選擇一個節點完成，該節點稱之為主節點，當主節點因為異常停掉時，整個網絡就會停滯，節點之間會一直詢問，阻塞，直到該間隔結束，下一個間隔重新選擇主節點。當網絡初步啟動，節點和交易較少時，Fabric網絡處理迅速，選舉間隔極短，但是，當節點數目和交易次數很多時，網絡處理變得緩慢，選舉間隔增加，每一次的阻塞時間都是很大的浪費。orderer節點選舉的主節點遭受異常壞掉，造成該間隔內整個系統阻塞的問題，屬于容錯問題，Fabric系統需要有一個支持主節點容錯的機制。

故本文在Fabric的基礎上，針對現階段系統不支持主節點容錯的問題，對Fabric系統架構進行演化，提出了一個支持主節點容錯的演化算法。

本文研究部分分為四部分：第一部分是引言，第二部分是相關工作;第三部分是算法設計;第四部分是實驗分析;第五部分是總結。

1 ?相關工作

中本聰的奠基性論文^[1]中，指出了區塊鏈的典型結構，對關鍵術語交易、時間戳服務器、工作量證明、網絡、激勵、回收硬盤空間、簡化的支付確認、價值的組合與分割、隱私進行了詳細敘述，最后進行計算，驗證了區塊鏈網絡的可行性。在這個設計中，巧妙地將節點容錯能力轉化為對于系統中算力的掌握程度，只要掌握的算力不超過系統總算力的50%，就不會系統造成影響。實質上是依賴于共識算法-Pow算法，但是該算法耗費資源極高，節點是否異常需要有6個區塊上鏈才能確定，時間間隔長，不適用于一般系統^[6-7]。

袁勇、王飛躍^[8]以比特幣為例，說明了區塊鏈的基礎架構模型，由數據層、網絡層、共識層、激勵層、合約層和應用層組成：

數據層：封裝了底層數據區塊以及相關的數據加密和時間戳等技術;

網絡層：包括分布式組網機制、數據傳播機制和數據驗證機制等;

共識層：主要封裝網絡節點的各類共識算法;

激勵層：將經濟因素集成到區塊鏈技術體系中來，主要包括經濟激勵的發行機制和分配機制等;

合約層：主要封裝各類腳本、算法和智能合約，是區塊鏈可編程特性的基礎;

應用層：封裝了區塊鏈的各種應用場景和? 案例。

邵奇峰、金澈清等^[9]結合了比特幣、以太坊、fabric等區塊鏈平臺，提出了另外一種相似但更為簡潔的區塊鏈架構模型，整體上可劃分為網絡層、共識層、數據層、智能合約層和應用層五個層次，其中不同之處在于數據層，這種結構中的數據層包括數據結構、數據模型和區塊存儲，激勵層并入共識層中。在論述區塊鏈劣勢時，提及了區塊鏈吞吐量、事務和并發處理、查詢統計、訪問控制以及可擴展性問題，沒有提及容錯方面。

徐曉冰、戚梟宏等^[10]把區塊鏈技術應用到物聯網上，部署智能合約為設備管理操作提供接口，把物聯網設備獨立于區塊鏈網絡之外，進而實現網絡的可伸縮性。后續之中還改進了PBFT算法，使之更有效率地替換拜占庭節點，實驗驗證了其有效性，但是容錯功能依然是作為共識算法的一部分，沒有改進。

甘俊、李強等^[11]針對拜占庭容錯共識算法的靜態網絡結構和主節點選取隨意，通信開銷較大的問題，進行改進，使節點可以動態地加入或退出，并且以最長鏈為選舉原則進行選舉，對選舉出來的節點增加了可信度和吞吐量，降低了時延，提高了安全性。該算法檢測出節點異常后，迅速結束當前周期，開啟新一輪選舉，降低了節點切換時間，但是沒有支持主節點容錯功能。

蔡維德、郁蓮等^[12]詳述了北航鏈，提出了賬戶區塊鏈模型和交易區塊鏈模型，滿足通信量巨大、快速響應、賬戶信息隱私等需要，并且可擴展性高，但是這個鏈的重點在于提高建塊速度、并行計算、節省算力方面，強調區塊鏈應用系統的開發，沒有關注主節點容錯。

朱立、俞歡等^[13]提出了新的高性能聯盟區塊鏈技術，通過業務邏輯與共識分離、存儲優化和數字簽名驗證優化等手段來提高聯盟鏈系統的交易性能，并且驗證了有效性。在此架構之中共識算法分離了出來，但是依然沒有擺脫容錯功能，整個系統還是依賴于共識算法進行處理。

Sara Saberi、Mahtab Kouhizadeh等^[14]將區塊鏈技術用于解決一些全球供應鏈管理的問題。全球的供應鏈系統和區塊鏈系統在結構上具有相似之處，都是分布式，現在的供應鏈管理嚴重依賴一些大型組織，具有集中式的特點。文章中提出把區塊鏈技術應用在供應鏈管理中，使得供應鏈不在集中于某幾個組織，具有更好的健壯性。文章指出在基礎的區塊鏈系統之上，更好的管理還得依靠智能合約，通過對其的嚴格審查，來確保安全。

關于區塊鏈的研究較少，大部分重點在于區塊鏈結構，把支持主節點容錯放在了共識算法中，少部分對共識算法進行了改進。本文提出的支持主節點容錯的orderer節點演化算法獨立于共識模塊，當主節點異常時，在當前周期內直接支持容錯，保證系統正常工作。

2 ?算法研究

2.1 ?需求分析

在Fabric系統結構中，數據傳輸過程如圖2。

（1）客戶端根據用戶輸入的數據、需要調用的chaincode函數和參數、時間戳和客戶端的簽名等信息，構建交易提案，依據設定好的背書策略發送給指定的Endorser節點;

（2）Endorser節點收到提案后，首先校驗簽名，保證合法性，然后進行背書操作，即根據提案中的信息，基于當前賬本狀態，調用chaincode函數模擬執行交易，生成結果并簽名，發送給客戶端。注意，此時只是模擬執行，并沒有更改當前的賬本狀態;

（3）客戶端收到回復后，驗證結果的簽名是否屬于給定的背書節點，保證合法性。然后，對模擬執行的結果進行校驗，若有多個回復信息，檢查是否一致。檢查通過后，對背書結果進行簽名，生成交易（transaction），發送給主orderer節點;

（4）主orderer節點是orderer節點列表依照Raft共識選舉出來的，在收到客戶端發送的交易后，首先會校驗簽名，保證合法性，然后對交易按照指定規則排序，并且打包生成塊，然后對生成的區塊簽名，之后發送給peer節點;

（5）peer節點中的Leader角色，負責與orderer節點通信，在收到區塊后，會廣播給組織內其余的peer節點，也就是Commit節點，在驗證通過后，會真正的執行交易，更新本地的數據庫。

由上述過程中，可看出，主orderer節點在起到了至關重要的作用，需要對主orderer節點進行容錯處理，但是在fabric系統中沒有，因此對fabric系統中orderer節點的結構進行演化，確保在主orderer節點產生異常的情況下，系統仍然可以正常工作。

相比于圖3，把orderer節點分為兩部分，新拿出的一部分作為備份orderer節點列表，時刻進行維護，按順序選取第一個節點作為備份orderer節點，時刻備份著主orderer節點的數據。當主orderer節

點異常時，備份orderer節點可以立即接管主orderer節點的業務，維護系統的正常運行。

2.2 ?演化模型

在原來的Fabric結構中，orderer節點與peer節點關系如下（假設此時主orderer節點已經收到客戶端發來的交易信息，為了簡潔，用戶、客戶端、背書節點和提交節點略去）：

主orderer節點收到客戶端發來的交易，對交易進行校驗、排序，然后按照一定規則打包成塊，發送給leader peer節點。此時的系統架構上，不具備容錯能力。

依照前面分析，在圖3-2的基礎上，添加了備份orderer節點來完成容錯。備份orderer節點需要知道主orderer的狀態，來及時的進行接管服務。本文參照觀察者模式^[15]，完成消息傳遞機制。

將主orderer節點作為被觀察者，備份orderer節點和leader peer節點作為觀察者，主orderer節點通過attach方法和detach方法來注冊、刪除具體觀察者，具體觀察者對象存儲在主orderer節點的concreteObservers字段中。主orderer節點就可以調用繼承的notify方法，在此方法中通過存儲的觀察者對象來調用它們自身的update方法，繼而完成對觀察者的通知。同時，主orderer節點需要把區塊發送給leader peer節點，也可以通過此機制來完成，使得兩者之間的耦合性降低。

備份orderer節點收到主orderer節點異常信息后，會啟動接管服務，利用備份好的數據，恢復主orderer節點的服務，去除Observer接口的方法，新添加Subject接口的方法，此時原來的備份orderer節點就變成了新的主orderer節點，在當前的時間間隔內繼續工作;原來的主orderer節點會進入檢測列表中，檢測正常，就會進入備份orderer節點列表;此時備份orderer節點列表中的第一個orderer節點，會自動成為新的備份orderer節點。

2.3 ?算法設計

在調整后的結構中，相對于被觀察者leader peer節點和備份orderer節點來說，其收到的消息是主orderer節點推送過來的，是被動接受的。這一般適用于主orderer節點在工作過程中陷入阻塞狀態，阻塞時間大于waitTime（等待時間）時，來通知備份orderer節點和leader peer節點。

算法1：異常感知算法（被動）

輸入：backupIP——備份orderer節點的IP地址

輸出：異常狀態信息

主orderer節點端：

1. backupOrderer=getOrderer（backupIP）? // 得到備份orderer節點對象

2. attach（backupOrderer）????????? // 注冊觀察者，存入觀察者列表中

3. IF 進入阻塞狀態 && 阻塞時間 > waitTime THEN

4. ??notify（異常狀態信息）??? // 通知觀察者

5. END

備份orderer節點端：

1. exceptionInfo=update（）????????????????? // 主orderer節點端的notify方法，本質上就是調用觀察者自身的update方法進行通知

2. print（exceptionInfo）

leader peer節點端：

1. exceptionInfo=update（）

2. print（exceptionInfo）

觀察者模式是典型的被動感知，有其局限性，當主orderer節點斷網時，就無法向觀察者備份orderer節點和leader peer節點推送消息，即備份orderer節點無法被動感知。此時就需要備份orderer節點主動感知主orderer節點異常的算法。

算法2：異常感知算法（主動）

輸入：主orderer節點的IP地址

輸出：主orderer節點異常信息

主orderer端：

1. 讀取本地IP，監聽本地端口

2. WHILE

3.??? IF 收到連接請求 THEN

4.??????? 建立連接

5.??????? Send（狀態信息）

6.??? END

備份orderer端和leader peer節點端：

1. 讀取主orderer的IP地址

2. WHILE

3.??? 向主orderer節點發送連接請求

4.??? IF 連接成功 THEN

5.??????? Receive（狀態信息）

6.??? ELSE

7.??????? print（主orderer節點異常）

8.??? END

9.??? sleep（intervalTime）

假設此時主orderer節點產生異常，已經無法正常工作，備份orderer節點已收到異常信息，準備接管其業務。

圖7是用一個正常工作的狀態，此時主orderer節點產生異常，備份orderer節點通過算法1被動感知或者算法2主動感知，得到其無法正常工作的消息，就會啟動自身的數據恢復服務和接管服務，代替主orderer節點工作，同時從備份orderer節點列表中，取出首位的備份orderer節點，進行數據備份服務。

算法3：orderer節點演化算法

輸入狀態：主orderer節點異常，無法工作

輸出狀態：備份orderer節點接管主orderer節點業務，正常工作

備份orderer端：

1. data=updateData（）?????? // 把數據從本地備份中恢復

2. Tx=receiveTx（data[sender]） // 通過備份的交易發送方，啟動接收交易服務，接受新的交易

3. getService（data[Tx]/Tx）??????? // 對備份中的交易和收到的新交易進行排序，打包成塊

4. sendBlock（data[receiver]）???? // 通過備份的區塊接收方，啟動發送區塊服務，把生成的區塊發送給指定的接收方

5. 監聽本地端口

6. WHILE

7. ??? IF 收到連接請求 THEN

8. ???????????? 建立連接

9.?????????????? Receive（新的備份orderer節點已經準備好）

10.???????????? attach（新的備份orderer節點）??????? // 注冊新的觀察者，必須確保新的備份orderer節點已經準備好

11. ?????????? WHILE

12.????????????????????? sendData（data）???????? // 循環發送數據，以便備份

13. ?????????? END? // 若產生異常，跳出循環

14.??? END

在備份orderer節點列表中，選擇當前第一個節點，成為新的備份orderer節點。

新的備份orderer節點端：

1. 向現在的主orderer節點（原備份orderer節點）發送請求

2. IF 建立連接 THEN

3.????? Send（備份節點已經就緒）

4.????? WHILE

5. ???????????? data=Receice（data）? // 循環接收當前主orderer節點發來的數據

6.? ?????????? saveData（data）???????? ??? // 保存

7.?? ??????? END ??????? // 若產生異常，跳出循環

8. END

備份節點接管之后，原來的主orderer節點有可能恢復正常，不能直接廢棄，此時備份orderer作為主orderer，要測試原來的orderer信息，如果正常，就放入后備orderer列表，等待使用。

算法4：orderer節點管理算法

輸入：主orderer的IP地址

輸出：備份orderer節點列表

主orderer端：

1. 監聽本地端口

2. WHILE

3.??? IF 收到連接請求 THEN

4.??????? 建立連接

5.??????? Send（狀態信息）

6.??? END

備份orderer端：

1. 讀取主orderer的IP地址

2. WHILE

3.??? 向主orderer發送連接請求

4.??? IF 建立連接 THEN

5.??????? Receive（狀態信息）

6.?????? ?IF 狀態良好 THEN

7.??????????? backupOrderers.add（主orderer節點）

8.??????? END

9.??? END

10.? ?IF 共識節點數量<3 THEN // 共識算法至少得需要3個節點

11. ??????????????????? orderer= backupOrderers.remove（）

12. ??????????????????? normalOrderers.add（orderer）

13.? ??????? END

14.???? sleep（intervalTime）

3 ?實驗分析

3.1 ?實驗數據

本實驗所用到的數據是英特集團的2018年和2019年的交易數據，股票代碼：000411，數據來自于網易財經。

在2018年和2019年中，共有488天進行過股票交易。實驗中，建立兩個賬戶，一個是英特集團賬戶，初始金額為2018/1/2的流通市值，即418226.9萬元，另一個賬戶代表股民，初始金額設定為10000萬元，每次進行兩筆交易，分別代表資金流入和資金流出，執行488次，代表488天的交易，合計976筆交易。

3.2 ?實驗環境

實驗基于官方測試樣例fabric-samples/first- network，對其進行了修改，由5個orderer節點和3個peer節點構成，5個orderer節點中，其中3個orderer節點要通過Raft共識進行選舉，2個orderer節點作為備份orderer節點列表;3個peer節點中，指定peer0擔任leader角色，負責與orderer組織通信，3個peer節點都擔任Endorser角色和Commit角色，負責背書和寫入區塊。

3.3 ?實驗分析

仿造主orderer節點陷入阻塞狀態，備份orderer節點被動感知異常的情況下，對應用演化算法前? 后系統的業務吞吐量、資源利用率和延遲，進行了分析。

3.3.1? 業務吞吐量

在吞吐量方面，fabric中對于讀和寫的處理效率是不同的，讀的效率要高于寫的效率，因此對讀寫分開進行測試。

由圖10可看出，隨著吞吐量的增加，讀操作和寫操作都出現了失敗案例，這是fabric本身的性能瓶頸。讀操作的TPS在500左右，寫操作的TPS在300左右，在這兩個界限之下，可保證交易的有效性。

相比于演化前的吞吐量，演化后的系統在讀操作上的TPS提高到520上下，寫操作的TPS提高到310上下。整體上，在吞吐量指標上，有了3%-4%的提升。

3.3.2? 資源利用率

通過自動化腳本對應用演化算法前后的數據進行采集，主要采集CPU和硬盤的使用數據，其中讀寫操作的比例是2∶1，CPU采用百分比，硬盤采用萬分比，結果如圖12。

由圖中可看出，在CPU的利用率上，當交易次數較少時，采用演化算法的系統使用的CPU資源要少一些，隨著交易次數的增加，無論是否采用演化算法，CPU的利用率都會達到100%，陷入瓶頸;在硬盤的利用率上，采用演化算法的系統比原系統使用的硬盤資源少，而且隨著交易數量的增加，會越來越明顯。

3.3.3? 延遲

在fabric系統中，主orderer節點作用是對收到的交易進行排序、打包，當收到的交易數量大于主orderer節點的處理能力時，多余的交易會進行排隊等待，繼而會造成延遲。實驗測量交易的平均等待時間，結果如圖13。

由圖中可看出，隨著交易次數的增加，平均每個交易的延遲會顯著降低，說明了演化算法中，orderer節點替換的時間要小于Raft共識重新選舉的時間。

3.4.4? 小結

應用演化算法的fabric系統，最主要的突破是降低了延遲。采用備份orderer節點接管主orderer節點的業務，是有效的，其花費的時間開銷小于共識算法重新選舉的時間開銷。

延遲降低后，單位時間內的交易吞吐量就會提高，但是本質上吞吐量取決于fabric系統內部的運算復雜度，交易的等待時間并不是決定性因素，因此系統吞吐量提高的幅度不大。

共識算法的選舉過程，需要進行安全校驗，即加解密操作，需要CPU運算;而orderer節點演化算法要求備份orderer節點恢復交易數據，對交易排序、打包，需要磁盤讀寫，因此，當交易次數少的時候，應用演化算法的系統需要的CPU資源就會降低。隨著交易次數的增加，限于硬件環境，CPU資源耗盡，進入瓶頸。

對于硬盤資源，延遲的降低，使得等待處理的交易減少，進而降低了這部分交易的存儲，同時也減少了日志信息。

4 ?結論

本文通過對fabric架構中的orderer節點進行演化，把orderer節點分出一部分，作為備份orderer節點，解決了主orderer節點異常問題。實驗表明，該算法能有效地降低延遲，進而提高fabric的運行效率。

參考文獻

1. Satoshi Nakamoto. Bitcoin： a peer-to-peer electronic cash system[OL]， available： https：//bitcoin.org/bitcoin.pdf， 2008.
2. Hyperledger Chinese document[OL]. https：//hyperledgercn. github.io/hyperledgerDocs.
3. 楊保華， 陳昌. 區塊鏈原理、設計與應用[M]. 北京： 機械工業出版社， 2017. 8.

1. 張增駿， 董寧， 朱軒彤， 等. 深度探索區塊鏈： Hyperledger技術與應用[M]. 北京： 機械工業出版社， 2018. 1.
2. 朱立， 俞歡， 詹士瀟， 等. 高性能聯盟區塊鏈技術研究[J]. 軟件學報， 2019， 30（6）： 1577-1593.
3. 葉聰聰， 李國強， 蔡鴻明， 等. 區塊鏈的安全檢測模型[J]. 軟件學報， 2018， 29（05）： 1348-1359.
4. Mauro C， Kumar E S， Chhagan L， et al. A Survey on Security and Privacy Issues of Bitcoin[J]. IEEE Communications Surveys & Tutorials， 2018： 1-1.
5. 袁勇， 王飛躍. 區塊鏈技術發展現狀與展望[J]. 自動化學報， 2016， 42（4）： 481?494.
6. 邵奇峰， 金澈清， 張召等. 區塊鏈技術：架構及進展[J]. 計算機學報. 2018（5）， 5（41）： 969-988.
7. 徐曉冰， 戚梟宏， 王建平， 等. 基于區塊鏈的物聯網可伸縮管理機制[J]. 計算機應用研究. 2019（6）.
8. 甘俊， 李強， 陳子豪， 等. 區塊鏈實用拜占庭容錯共識算法的改進[J]. 計算機應用， 2019， 39（07）： 2148-2155.
9. 蔡維德， 郁蓮， 王榮， 等. 基于區塊鏈的應用系統開發方法研究[J]. 軟件學報， 2017， 28（6）： 1474-1487.
10. 朱立， 俞歡， 詹士瀟， 等. 高性能聯盟區塊鏈技術研究[J]. 軟件學報， 2019， 30（6）： 1577-1593.
11. Sara Saberi， Mahtab Kouhizadeh， Joseph Sarkis & Lejia Shen. Blockchain technology and its relationships to sustainable supply chain management[J]， International Journal of Production Research， 2019.
12. Erich Gamma， Richard Helm， Ralph Johnson， John Vlissides. 設計模式： 可復用面向對象軟件的基礎[M]. 李英軍， 馬曉星， 蔡敏等譯. 北京： 機械工業出版社， 2007. 1.