基于區塊鏈的供應鏈托管系統設計

李朝放，盧清華

（中國石油大學（華東）計算機科學與技術學院，山東青島 266580）

現代供應鏈復雜多變，企業在發展過程中的運營管理存在諸多問題。一方面，供應鏈網絡的管理風險不易把控且存在不良交易，造成了供應鏈信任短缺的現象；另一方面，在中心化的系統中，若關鍵設備或服務中斷運行，可能會對鏈上的公司造成嚴重損害[1-2]。

基于分布式賬本的區塊鏈提供了高可信的安全環境和自動化交易的能力，去中心化的架構也使歷史交易信息在區塊中得到保護，有效避免數據篡改和惡意刪除。許多政府和企業都在探索區塊鏈技術的更多應用場景，但是仍然缺少系統、完整的區塊鏈解決方案來優化供應鏈支付問題。

基于此，該文提出了一種基于區塊鏈和物聯網的供應鏈托管架構，以實現供應鏈的去中心化管理；設計研究了供應鏈支付托管算法，做到自動化執行交易交割；最后實現了系統原型并完成性能測試工作，結果表明所提結構和算法具有較高的可行性和良好的性能，為供應鏈提供了高信任度的環境和可以安全執行的交易合約。

1 相關背景

目前供應鏈越來越依賴于高效可信的運輸和通信系統[3]。一些企業采用了供應鏈彈性技術，使供應鏈具有自動恢復和自我重建的能力[4]；或將供應鏈內部和外部進行整合，并構建最佳匹配狀態[5]等。但是這些仍然不能避免改進方案受到單點故障、人為因素和不良商業交易行為的影響，導致網絡環境的受信程度不高，敏感關鍵信息存在被篡改的可能，造成交易甚至企業的嚴重損失[6-7]。

區塊鏈作為一種去中心化分布式賬本技術，使用共識算法、多種加密和激勵策略等手段，搭建了一種去中心化的、無需信任的分布式對等網絡和一種鏈式賬本數據結構。這種技術依托去中心化架構，從而實現了點對點交易和分布式自治節點集群，很好地解決了單點故障以及數據、身份信任問題[8-9]。

如圖1 所示，區塊鏈基于共識的鏈式結構從源頭上保證了歷史數據的不可篡改性，配合共識算法和激勵策略保證鏈上數據的安全性和完整性[10-12]。

圖1 區塊數據結構

智能合約是指在分布式賬本的多個節點上同步運行的代碼腳本，且能夠做到由互不信任的節點正確執行，而不需要第三方可信機構。由于智能合約的自動執行特性，為依賴數據驅動事務的許多領域提供了機遇，目前越來越多的開發者正致力于開發不同類型的智能合約，例如金融、公證、政務、物流等[13-15]。

目前國內區塊鏈在供應鏈上也有實驗性應用，但主要集中在農產品溯源和防偽等問題上[16]，對供應鏈的架構升級和支付管理缺少深入研究。

2 基于區塊鏈的供應鏈托管架構

2.1 系統整體架構

圖2 展示了所提供應鏈托管系統的系統架構圖。在Fabric 網絡中的每一個點代表一個服務器節點。若干服務器節點組成一個組織，組織內部的節點數并不限制，按照真實機構組成來劃分組織，而組織中必須確定錨節點來代表本組織與其他節點的通信，如組織1 中的錨節點為服務器節點0，而組織之間或節點之間的通信是建立在通道之上。

圖2 供應鏈托管系統架構

通道是任意節點組成的一個子區塊鏈網絡，這些節點可以來自同一組織也可以跨組織，并且節點能夠在通道建立之后靈活加入。但節點不能退出，同樣通道也不可撤銷。需要說明的是，各通道之間不可通信，各擁有獨立分布式賬本。另外，通道也是鏈碼的安裝基礎，相同鏈碼只能在同一通道中安裝一次，但是可以通過版本迭代來升級鏈碼。

客戶端系統由Fabric SDK 開發，安裝在服務器節點和物聯網設備上。客戶端中設定了各服務器節點的IP 地址和名稱以及通道和鏈碼等的名稱。客戶端系統中開發了通道和節點管理器，服務器節點擁有使用該功能的權限，可以實現創建通道和節點加入的管理；交易廣播器由物聯網設備使用，可以實現交易的發起和廣播，廣播的目標節點為服務器節點中的peer 節點，也稱背書節點，并在此節點上模擬執行交易，結果返回至客戶端系統中；交易排序器由物聯網設備調用，該功能可以將得到背書的交易發送至orderer 節點進行排序，并最終上鏈。物聯網設備對客戶端系統中的功能調用是自動化的，需要傳感器數據達到預定閾值，從而觸發設備調用相應功能。

2.2 支付托管算法

算法1 描述了基于區塊鏈的供應鏈支付托管算法。在算法中對每個公司ci進行如下循環：從通道中獲得ci的當前賬本信息l，使用定義的prase()函數對l進行解析，獲得當前合同conc以及歷史合同conh。對當前合同conc進行循環解析，并與參數con對比，若conci與con 不相同則保留conci；若相同，則跳過當前conci，保留后續所有合同內容，并將當前conci接入conh，成為歷史合同。

接下來使用算法中定義的組裝函數assemble()，將更改后的conc和conh整合至賬本信息l中，并對l中的資產asset 按照con 的轉賬合同內容通過轉賬函數transfer()進行轉賬操作。

最后將更新的賬本信息l進行廣播并上傳至鏈上。首先定義結構體pair，包括背書節點peer、交易proposal 以及交易返回值responds。pr 為背書節點，在所有背書節點中循環下述算法：

將pr 賦值于pair.peer，待執行交易p 賦值給pair.proposal。初始化本地背書客戶端，使用該客戶端與區塊鏈中所有背書節點通信，并將返回值賦值pair.responds。再將節點相關狀態更新為connected，并將pair 整體添加至pairs 中。最后將pairs 的內容轉換為易于讀取數據的proposalResponds，并返回該數據結構。

3 系統原型實現

3.1 服務器節點原型實現

該系統節點集群使用Vmware 虛擬機創建4 臺服務器，操作系統為Ubuntu18.04，安裝Hyperledger Fabric1.4 分支版本，區塊鏈共識算法采用Apache Kafka 共識。4 臺服務器的配置如表1 所示。

表1 節點集群服務器配置

為實現供應鏈上全流程操作托管，該系統在區塊鏈上開發并安裝了如表2 的智能合約。智能合約中允許聲明兩類機構實體，一為普通公司，一為物流公司。其中普通公司為簽署各種合同的主體；相應的，合同也分為兩種：普通公司的商業合同和物流公司的物流交易合同；表中增加請求是指公司發布購買意愿或售出意愿，等待其他公司根據請求簽訂合同；另外，完成請求、完成合同和轉賬操作均為不可直接調用的智能合約，請求的完成將在增加對應合同時自動執行；商業合同的完成是在對應物流協議完成時被調用執行，而物流協議的觸發則需要通過物聯網設備的數據傳輸，實現全流程自動化。

表2 智能合約說明

3.2 客戶端原型實現

圖3展示了Fabric物聯網客戶端的類圖。APIEscrow為main 函數所在類，在該類中主要聲明了Fabric 網絡和通道的基本參數，以及創建、初始化客戶端、調用智能合約等方法。APIEscrow 類關聯的HFClient類是實現客戶端方法的主要Java 類。在HFClient 類中，聲明和定義了客戶端相關的基本參數，包括客戶端線程執行器核心池大小、通道Map 等。類中的主要方法有通道的加載、創建和獲取以及智能合約相關操作、通過獲取和查詢通道信息等方法。

圖3 客戶端類圖

BuildClientDTO 類和ChaincodeID 類是創建客戶端和安裝、初始化智能合約必需的Java 類。在這兩個類中聲明了客戶端和智能合約的必要參數，如mspID、msp 路徑等。

APIHandler 是另一個核心Java 工具類。其中createChannel 方法將通過HFClient 客戶端對象獲取到所需環境參數和orderer 節點數據進行通道的創建，并獲取CreateChannelDTO 對象的數據，將需要的peer節點加入至通道。另外智能合約的安裝、初始化、升級和查詢等操作也可以在APIHandler 類中完成。

圖4 展示了交易在客戶端和服務器節點間的流程。步驟一，由客戶端發起交易，并通過該系統交易廣播器廣播至全體背書節點，背書節點進行交易模擬，通過后簽署背書簽名；步驟二，客戶端收集所有背書簽名；步驟三，客戶端再次通過交易廣播器將得到簽名的交易發送至排序節點，獲取排序服務；步驟四，排序節點驗證交易合法性并給客戶端返回值，最后將合法交易送至提交節點。

圖4 交易流程圖

4 性能測試

此節對該托管系統進行性能測試。使用樹莓派中的Fabric 客戶端進行通道創建和peer節點加入，每次運行耗時情況如圖5 所示，運行時間穩定在2 s 上下，平均運行時間為1.983 s，完全可以滿足企業需求。

圖5 通道創建運行時間

圖6 展示了使用Fabric 客戶端進行智能合約調用的性能測試結果，圖中的數據為運行多次智能合約調用的累計耗時。從圖中可以看出累計運行時間成線性增長，平均單次調用智能合約的運行時間為0.397 s，可以實現該供應鏈托管系統的秒級響應。

圖6 調用智能合約累計運行時間

5 結束語

文中設計并實現了一個基于區塊鏈的供應鏈托管系統。該系統結合區塊鏈網絡和物聯網，實現了供應鏈商業合同的自動化執行，避免惡意篡改，做到去中心化地管理供應鏈。利用區塊鏈客戶端實現了網絡中輕節點調用鏈上智能合約，并且從創建通道到調用智能合約的累計時間可以滿足企業的實際需求。該系統的下一步工作是實現動態增加服務器節點，并接入更真實的物聯網設備，如RFID、紅外傳感器等。