面向冷鏈物流的區(qū)塊鏈技術(shù)方案研究與實現(xiàn)

張 森，葉 劍，李國剛

1.華僑大學(xué) 信息科學(xué)與工程學(xué)院，福建 廈門361021

2.中國科學(xué)院 計算技術(shù)研究所，北京100190

1 引言

近年來，隨著人們生活水平的不斷提高以及電子商務(wù)的普及，我國冷鏈物流市場也快速發(fā)展。所謂冷鏈物流，泛指一些特殊商品（比如食品、藥品）在其加工、貯藏、運輸、分銷、零售等各環(huán)節(jié)，需要始終保持一定溫度的物流運輸方式，從而保證商品質(zhì)量[1]。

目前的冷鏈物流系統(tǒng)大都采用物聯(lián)網(wǎng)技術(shù)來提高物流系統(tǒng)的信息化水平，比如文獻[2]通過物聯(lián)網(wǎng)技術(shù)實現(xiàn)對冷鏈中貨物的有效、快速的監(jiān)控，但這種方式?jīng)]有解決數(shù)據(jù)中心化存儲的弊端，仍然存在以下問題[3-4]：（1）缺乏信任的問題。冷鏈物流行業(yè)要求高，成本高，數(shù)據(jù)造假、跑路等不信任行為頻頻出現(xiàn)，大大提高了貨損率。（2）運輸過程不透明。物流企業(yè)在運輸過程中，為了降低成本，可能存在運輸過程中關(guān)閉制冷機、快到目的地時再打開制冷機的現(xiàn)象，不能做到全程冷鏈。（3）數(shù)據(jù)存儲不透明?，F(xiàn)在溫度數(shù)據(jù)大多存儲在承運方和倉儲企業(yè)的中心化數(shù)據(jù)庫中，貨主無法方便獲取數(shù)據(jù)。中心數(shù)據(jù)庫記錄的方式可靠性不高，重要數(shù)據(jù)需要進行冗余備份。（4）資源共享難度大。在采用第三方物流運輸時，尤其在農(nóng)產(chǎn)品領(lǐng)域，存在貨物分散的特點。目前存在著運力不透明的問題，難以實現(xiàn)資源共享和設(shè)備利用的最大化。

為此，本文提出一種面向冷鏈物流行業(yè)的區(qū)塊鏈技術(shù)解決方案，利用區(qū)塊鏈技術(shù)所具有的去中心化、去信任化、數(shù)據(jù)防篡改等特點[5]，建立安全可信的冷鏈物流數(shù)據(jù)共享機制，提高運輸過程、數(shù)據(jù)存儲等環(huán)節(jié)的透明性。

2 相關(guān)工作

2.1 區(qū)塊鏈

隨著比特幣等電子貨幣的廣泛傳播，作為其底層核心模塊的區(qū)塊鏈技術(shù)成為工業(yè)界和學(xué)術(shù)界討論的熱點[6]。所謂區(qū)塊鏈技術(shù)是一種由多方共同維護的，使用密碼學(xué)保證傳輸和訪問安全，能夠?qū)崿F(xiàn)一致性存儲、難以篡改、防止抵賴的記賬技術(shù)，也稱為分布式賬本技術(shù)[7]。到目前為止區(qū)塊鏈技術(shù)已經(jīng)經(jīng)歷了三個發(fā)展階段[8-10]，即數(shù)字貨幣為代表的區(qū)塊鏈1.0時代；融入智能合約的區(qū)塊鏈2.0時代；將區(qū)塊鏈應(yīng)用于更多行業(yè)場景的區(qū)塊鏈3.0階段。在區(qū)塊鏈系統(tǒng)中，所有已提交的事物都存儲在鏈中，當(dāng)新的交易被確認時，將增加鏈的長度，而不會對前面的數(shù)據(jù)進行修改，從而保證了數(shù)據(jù)的完成性[11]。區(qū)塊鏈系統(tǒng)具有分布式高冗余存儲、時序數(shù)據(jù)且不可篡改和偽造、去中心化信用、自動執(zhí)行的智能合約、安全和隱私保護等顯著的特點[12]，使得區(qū)塊鏈的應(yīng)用已從金融領(lǐng)域延伸到實體領(lǐng)域，電子信息存證、版權(quán)管理和交易、產(chǎn)品溯源、數(shù)字資產(chǎn)交易、物聯(lián)網(wǎng)、智能制造、供應(yīng)鏈管理等領(lǐng)域[13]。例如，薛騰飛等人[14]提出一個基于區(qū)塊鏈的醫(yī)療數(shù)據(jù)共享模型，適用于解決各醫(yī)療機構(gòu)數(shù)據(jù)共享的難題；瑞士初創(chuàng)公司Modum[15]與蘇黎世大學(xué)合作設(shè)計了一套基于區(qū)塊鏈的制藥供應(yīng)鏈系統(tǒng)，以確保藥物的安全運送；Guan等人[16]研究了區(qū)塊鏈技術(shù)在智能電網(wǎng)中的應(yīng)用；Elisa等人[17]提出了一種基于區(qū)塊鏈技術(shù)的電子政務(wù)系統(tǒng)，增進了各公共部門之間的信任；Cobe等人[18]設(shè)計了一種應(yīng)用于聯(lián)網(wǎng)車輛信息管理的區(qū)塊鏈框架。

根據(jù)實際應(yīng)用場景和需求，區(qū)塊鏈技術(shù)可以分為三種應(yīng)用模式，即公共鏈、聯(lián)盟鏈和私有鏈[19]。公共鏈是以比特幣為代表的最初的區(qū)塊鏈形態(tài)，任何節(jié)點都可以自由加入，并參與到賬本數(shù)據(jù)的讀寫、驗證和共識，共同維護賬本數(shù)據(jù)；聯(lián)盟鏈是一種有準入控制機制的區(qū)塊鏈形態(tài)，適用于多個實體構(gòu)成的組織或者聯(lián)盟；私有鏈是一種中心化的區(qū)塊鏈形態(tài)，完全由一個組織控制，適用于特定機構(gòu)的內(nèi)部數(shù)據(jù)管理和審計。

2.2 Hyperledger Fabric

Hyperledger Fabric[20]是一種被廣泛應(yīng)用的聯(lián)盟區(qū)塊鏈平臺，以模塊化架構(gòu)為基礎(chǔ)，提供可切換、可擴展的組件，具有高度的保密性、彈性、可擴展性和靈活性。其克服了比特幣、以太坊等公有鏈項目吞吐量低、無隱私機制、共識算法低效等的缺陷，更適用于商業(yè)場景，使用戶能夠方便地開發(fā)商業(yè)應(yīng)用。

在Fabric網(wǎng)絡(luò)模型中，主要包括客戶端節(jié)點、Peer節(jié)點、CA節(jié)點和Orderer節(jié)點四種組件。客戶端節(jié)點主要作用是和Fabric系統(tǒng)交互，實現(xiàn)對區(qū)塊鏈系統(tǒng)的操作，包括管理類操作和鏈碼類操作。Peer節(jié)點是區(qū)塊鏈去中心化網(wǎng)絡(luò)中的對等節(jié)點，按照功能主要劃分為背書節(jié)點（Endorser）和確認節(jié)點（Committer）。背書節(jié)點主要對交易預(yù)案進行校驗、模擬執(zhí)行和背書簽名，確認節(jié)點則負責(zé)檢驗交易的合法性，并更新和維護區(qū)塊鏈數(shù)據(jù)和賬本狀態(tài)。Orderer節(jié)點是排序服務(wù)節(jié)點，負責(zé)對各個節(jié)點發(fā)過來的交易進行排序。CA節(jié)點主要是給Fabric網(wǎng)絡(luò)中的成員提供基于數(shù)字證書的身份信息，可以生成或者注銷成員的身份證書。

2.3 Diffie-Hellman密鑰交換算法

Diffie-Hellman[21]（簡稱DH）是密鑰交換算法之一，它的作用是保證通信雙方在非安全的信道中安全地交換密鑰。在DH算法中，發(fā)送方和接收方共同產(chǎn)生一個只有雙方知道的私有的密鑰，其產(chǎn)生過程是使用自己的私鑰和對方的公鑰經(jīng)過計算得到共享密鑰。

首先，通信雙方A和B協(xié)商一個大的素數(shù)n和g，g是模n的本原元，這兩個數(shù)不必是秘密的。故A和B可以通過不安全的途徑協(xié)商它們，它們也可以在一組用戶中公用。其主要運算過程如下：

（1）A選取一個大的隨機整數(shù)x，并計算X=gxmod n，將X發(fā)送給B。

（2）B也選取一個大的隨機整數(shù)y，并計算Y=gymod n，將Y發(fā)送給A。

（3）A計算k=Yxmod n。

（4）B計算k′=Xymod n。

經(jīng)過以上過程，則有k=k′=gxymod n，因此，k和k′可以看做是通信雙方各自獨立計算，又相互知道的密鑰。

3 方案整體設(shè)計

3.1 整體架構(gòu)

圖1 方案整體架構(gòu)示意圖

本文提出的面向冷鏈物流行業(yè)的區(qū)塊鏈技術(shù)解決方案，主要利用物聯(lián)網(wǎng)技術(shù)和區(qū)塊鏈技術(shù)相結(jié)合，其整體架構(gòu)如圖1所示，包括證書中心機構(gòu)、環(huán)境數(shù)據(jù)上鏈模塊、訂單數(shù)據(jù)上鏈模塊、智能合約模塊以及Fabric區(qū)塊鏈底層平臺[22]。

（1）證書中心機構(gòu)負責(zé)為物聯(lián)網(wǎng)設(shè)備和區(qū)塊鏈網(wǎng)絡(luò)模型中各組織的Peer節(jié)點、Orderer節(jié)點、用戶等提供數(shù)字證書的生成、身份的認證。（2）環(huán)境數(shù)據(jù)上鏈模塊包括物聯(lián)網(wǎng)模塊和交易緩沖模塊。物聯(lián)網(wǎng)模塊主要負責(zé)冷鏈過程的環(huán)境數(shù)據(jù)的采集與處理。交易緩沖模塊通過引入消息隊列機制對物聯(lián)網(wǎng)模塊傳輸來的數(shù)據(jù)進行緩存。（3）訂單數(shù)據(jù)上鏈模塊包括應(yīng)用模塊和加密傳輸模塊。應(yīng)用模塊通過調(diào)用證書中心的相關(guān)接口實現(xiàn)各組織用戶的注冊、證書的生成，以及通過調(diào)用智能合約中的程序?qū)崿F(xiàn)訂單數(shù)據(jù)的上鏈和查詢操作。加密傳輸模塊對每一筆訂單數(shù)據(jù)信息加密后上傳到區(qū)塊鏈網(wǎng)絡(luò)，保證訂單信息不會被非相關(guān)方獲取。（4）智能合約模塊負責(zé)提供數(shù)據(jù)上鏈和查詢的接口，包括合約的部署、初始化、實例化、鏈碼交互。冷鏈物流的各參與主體部署相同的智能合約，一旦合約容器建立，合約內(nèi)容將無法修改。（5）Fabric區(qū)塊鏈底層平臺是整個系統(tǒng)的核心組成部分，主要有四個方面的功能，一是通過多通道隔離機制，為每個物流過程創(chuàng)建一個自己獨有的通道實現(xiàn)數(shù)據(jù)隔離和商業(yè)信息保護；二是使用分布式賬本存儲技術(shù)實現(xiàn)賬本數(shù)據(jù)、區(qū)塊索引、狀態(tài)數(shù)據(jù)、歷史數(shù)據(jù)等存儲結(jié)構(gòu)；三是基于Gossip的P2P數(shù)據(jù)分發(fā)，Gossip模塊負責(zé)連接排序服務(wù)和Peer節(jié)點，實現(xiàn)從單個源節(jié)點到所有節(jié)點高效的數(shù)據(jù)分發(fā)，實現(xiàn)不同節(jié)點的狀態(tài)同步、動態(tài)節(jié)點的增加和網(wǎng)絡(luò)分區(qū)；四是基于Kafka的排序服務(wù)，利用Kafka作為交易的消息隊列，實現(xiàn)共識服務(wù)，保證各節(jié)點數(shù)據(jù)的一致性。

3.2 網(wǎng)絡(luò)結(jié)構(gòu)

冷鏈物流主要涉及發(fā)貨方、物流企業(yè)、收貨方等多種業(yè)務(wù)角色，三方作為冷鏈物流中的上下游企業(yè)都是利益相關(guān)方，每筆業(yè)務(wù)由三方共同完成，且需要實現(xiàn)可信的數(shù)據(jù)共享、冷鏈數(shù)據(jù)的可追溯防篡改。因為物流平臺中會包含其他的發(fā)貨方或者收貨方，所以為保護商業(yè)機密并實現(xiàn)數(shù)據(jù)隔離，系統(tǒng)將引入Fabric的多鏈多通道機制，為每個物流過程創(chuàng)建一個通道，每個通道內(nèi)只包含此次物流過程涉及的組織[23]。在單個通道內(nèi)，本方案的網(wǎng)絡(luò)結(jié)構(gòu)模型，如圖2所示。

圖2 冷鏈物流系統(tǒng)網(wǎng)絡(luò)模型圖

發(fā)貨方、物流運輸方、收貨方三方映射為Fabric中的三個組織，三個組織處于相互對等的地位，形成聯(lián)盟式管理方式，三方共同參與聯(lián)盟鏈的管理。該系統(tǒng)選擇基于Kafka的共識機制，實現(xiàn)高吞吐量的數(shù)據(jù)分發(fā)。每個組織內(nèi)有一個CA服務(wù)器，用來生成組織內(nèi)的相關(guān)證書（包括組織的證書、組織中所有節(jié)點的證書，組織中所有用戶的證書），只有獲得證書的用戶，才能通過調(diào)用SDK的相關(guān)接口對區(qū)塊鏈數(shù)據(jù)進行操作。每個組織內(nèi)可以包含多個Peer節(jié)點，每個Peer節(jié)點都將部署相關(guān)鏈碼，分別承擔(dān)數(shù)據(jù)背書、數(shù)據(jù)備份以及通信等任務(wù)。同時本方案還將給每個Peer節(jié)點配置了CouchDB數(shù)據(jù)庫，以實現(xiàn)更為豐富的查詢功能。

4 身份認證

身份認證是區(qū)塊鏈網(wǎng)絡(luò)建立和數(shù)據(jù)上鏈的基礎(chǔ)，只有經(jīng)過認證的節(jié)點才能加入?yún)^(qū)塊鏈網(wǎng)絡(luò)、只有經(jīng)過認證的用戶才能執(zhí)行數(shù)據(jù)上鏈和查詢。本方案基于Fabric的認證體系，實現(xiàn)節(jié)點的身份認證、物聯(lián)網(wǎng)設(shè)備的身份認證。

4.1 節(jié)點的身份認證

節(jié)點的身份認證主要包括Orderer節(jié)點和Peer節(jié)點的身份注冊并生成MSP證書。所謂MSP即成員管理服務(wù)，用戶抽象化各成員間的控制結(jié)構(gòu)關(guān)系。首先，根據(jù)所設(shè)計的網(wǎng)絡(luò)模型修改配置文件信息，即每個組織對應(yīng)一個MSP，一個組織內(nèi)包含三個Peer節(jié)點，一個排序服務(wù)節(jié)點，一個CA節(jié)點。然后，cryptogen模塊會根據(jù)配置文件生成后續(xù)模塊運行所需要的MSP證書文件，每個MSP證書文件中包括根CA證書、中間CA證書和管理員證書等。接下來，需要將生成的證書信息配置到創(chuàng)世區(qū)塊和創(chuàng)世交易中，生成創(chuàng)世區(qū)塊和創(chuàng)世交易通道文件。至此，節(jié)點的身份認證與通道配置完成，只需要等待區(qū)塊鏈網(wǎng)絡(luò)啟動即可。

4.2 物聯(lián)網(wǎng)設(shè)備的身份認證

物聯(lián)網(wǎng)設(shè)備的身份認證采用將設(shè)備MAC地址寫入到數(shù)字證書中的方法，使得物聯(lián)網(wǎng)設(shè)備和數(shù)字證書一一對應(yīng)，避免盜用數(shù)字證書使用其他設(shè)備上傳虛假數(shù)據(jù)的行為。具體流程如圖3所示。

圖3 物聯(lián)網(wǎng)設(shè)備身份認證流程圖

步驟1服務(wù)器端根據(jù)設(shè)備ID讀取上下文信息。

步驟2根據(jù)讀取到的配置信息判斷該設(shè)備是否存在，如果設(shè)備已經(jīng)存在，則返回設(shè)備信息，如果設(shè)備不存在，則進入步驟3。

步驟3獲取負責(zé)提交設(shè)備注冊信息的Admin信息。

步驟4判斷登記員Admin是否存在，如果存在，則進入步驟6，如果不存在，則進入步驟5。

步驟5初始化登記員Admin信息，配置Admin的hf.Registrar.Roles屬性，使其獲得登記員的登記權(quán)限，然后再配置Attributes屬性，使其具有登記物聯(lián)網(wǎng)設(shè)備的權(quán)限，然后再通過fabric-ca服務(wù)器創(chuàng)建Admin實例。

步驟6根據(jù)物聯(lián)網(wǎng)設(shè)備的MAC地址，配置其X.509證書參數(shù)，設(shè)置設(shè)備ID，設(shè)置設(shè)備所屬公司部門，設(shè)置設(shè)備的唯一標識符MAC地址，設(shè)置證書角色為user。

步驟7登記員向fabric-ca服務(wù)器調(diào)用register請求，登記設(shè)備信息，fabric-ca服務(wù)器驗證請求生成用戶注冊的Secret。

步驟8利用設(shè)備信息和返回的Secret，調(diào)用Enroll接口，請求生成證書和私鑰。

步驟9保存設(shè)備信息，并設(shè)置設(shè)備的Context。

經(jīng)過以上步驟，每個物聯(lián)網(wǎng)設(shè)備都有一個唯一的身份證書，且身份證書和自己的物理信息相關(guān)聯(lián)，以后每次請求區(qū)塊鏈網(wǎng)絡(luò)將會驗證設(shè)備的真實性，從而保證了數(shù)據(jù)來源的真實性。

5 數(shù)據(jù)上鏈系統(tǒng)

本方案中數(shù)據(jù)主要分為兩類：訂單數(shù)據(jù)和環(huán)境數(shù)據(jù)。其中，訂單數(shù)據(jù)指物流訂單信息，包括收發(fā)人地址、聯(lián)系方式、商品信息等，該數(shù)據(jù)包含大量公民個人信息，為防止公民個人信息泄露，訂單數(shù)據(jù)需要經(jīng)過加密傳輸單元上傳到區(qū)塊鏈服務(wù)器端。環(huán)境數(shù)據(jù)主要指有物聯(lián)網(wǎng)模塊的傳感器設(shè)備采集是溫濕度、大氣壓等冷鏈過程中的數(shù)據(jù)，考慮該數(shù)據(jù)實時性較強、且采集速度和上鏈速度需要實時匹配等問題，該數(shù)據(jù)需要經(jīng)過消息隊列模塊之后進行上鏈。

5.1 訂單數(shù)據(jù)上鏈系統(tǒng)

本系統(tǒng)設(shè)計的加密傳輸模塊采用密鑰交換協(xié)議（Diffie-Hellman密鑰交換算法）和對稱加密算法（AES對稱加密算法）相結(jié)合的方案，即通過密鑰交換協(xié)議產(chǎn)生對稱加密的密鑰，然后使用對稱加密算法對訂單信息加密，從而保證傳輸過程中無明文出現(xiàn)，保護了用戶隱私，算法時序圖如圖4所示。

步驟1發(fā)貨方在用戶客戶端向區(qū)塊鏈服務(wù)器端發(fā)送生成服務(wù)器端的公私鑰的請求。

步驟2服務(wù)器端執(zhí)行DH算法的generateKeys（）方法，根據(jù)設(shè)定的素數(shù)以及素數(shù)長度，產(chǎn)生服務(wù)器端的公私鑰對。

步驟3區(qū)塊鏈服務(wù)器端將生成的密鑰返回給用戶客戶端。

步驟4創(chuàng)建客戶端的DH實例，采用與服務(wù)器端相同的素數(shù)。

圖4 加密傳輸模塊時序圖

步驟5用戶客戶端執(zhí)行DH算法的generateKeys（）方法，根據(jù)設(shè)定的素數(shù)以及素數(shù)長度，產(chǎn)生客戶端的公私鑰對。

步驟6客戶端根據(jù)服務(wù)器端的公鑰，計算生成對稱密鑰key1，并利用key1對訂單信息order進行加密，生成加密后的訂單信息COrder即：

Key1=client.computeSecret（serverPub）

COrder=Enc（order，key1）

步驟7將客戶端公鑰cli-pub、加密訂單COrder發(fā)送到區(qū)塊鏈服務(wù)器。

步驟8區(qū)塊鏈服務(wù)器端根據(jù)客戶端的公鑰，計算生成對稱密鑰key2，根據(jù)DH算法可得key1恒等于key2，所以便可以利用key2將COrder解密，得到訂單的詳細信息，即：

Key2=server.computeSecret（clientPub）

COrderTxt=Dec（COrder，key2）

步驟9將訂單信息發(fā)送到智能合約模塊，完成數(shù)據(jù)上鏈。

步驟10將執(zhí)行結(jié)果返回給用戶客戶端。

5.2 環(huán)境數(shù)據(jù)上鏈系統(tǒng)

環(huán)境數(shù)據(jù)上鏈系統(tǒng)主要包括物聯(lián)網(wǎng)模塊和消息隊列模塊，實現(xiàn)冷鏈環(huán)境數(shù)據(jù)的采集、處理、緩存、上鏈等過程。其中，物聯(lián)網(wǎng)模塊由傳感器設(shè)備和Redis[24]內(nèi)存數(shù)據(jù)庫組成。Redis數(shù)據(jù)庫為內(nèi)存數(shù)據(jù)庫，其讀寫速度非常高，能滿足系統(tǒng)需求，Redis數(shù)據(jù)庫的引入使得數(shù)據(jù)采集和數(shù)據(jù)上傳分離，有效解決因上傳等待延遲造成數(shù)據(jù)采集遺漏的問題，同時也起到了數(shù)據(jù)緩存和備份的作用。具體流程如圖5所示。

步驟1傳感器設(shè)備負責(zé)采集溫度、濕度和大氣壓強數(shù)據(jù)，每秒鐘采集60次數(shù)據(jù)記為originalData，將這60個數(shù)據(jù)為一組，求其平均值獲得chainData，作為最終上鏈的數(shù)據(jù)，以此來減小傳感器采集數(shù)據(jù)的誤差，即originalData=[Ti,Pi,Hi]

圖5 環(huán)境數(shù)據(jù)上鏈流程圖

步驟2將處理后的數(shù)據(jù)data存儲在本地數(shù)據(jù)庫Redis中。

步驟3讀取Redis數(shù)據(jù)庫，將數(shù)據(jù)提交到區(qū)塊鏈服務(wù)器端的交易消息隊列中，返回數(shù)據(jù)提交結(jié)果。

步驟4讀取消息隊列中的數(shù)據(jù)，然后提交數(shù)據(jù)到智能合約模塊。

步驟5智能合約調(diào)用相關(guān)接口將數(shù)據(jù)保存在區(qū)塊鏈賬本中，如果數(shù)據(jù)成功寫入?yún)^(qū)塊鏈賬本，則相應(yīng)的消息出隊，如果數(shù)據(jù)寫入失敗，則相應(yīng)的數(shù)據(jù)消息仍然保存在隊列中，等待下一次上鏈。

6 智能合約

Fabric中的智能合約被稱為鏈碼[25]，是運行在基于Docker的安全容器中的獨立應(yīng)用程序，實現(xiàn)冷鏈環(huán)境數(shù)據(jù)和物流訂單數(shù)據(jù)的上鏈（包括訂單的發(fā)布、確認和簽收）、狀態(tài)數(shù)據(jù)查詢、歷史數(shù)據(jù)查詢以及合約方法級的權(quán)限控制等功能。

6.1 權(quán)限控制合約

目前，F(xiàn)abric不能對合約方法進行權(quán)限控制，區(qū)塊鏈網(wǎng)絡(luò)中的所有合法用戶均可對通道內(nèi)的所有合約方法進行操作，為保證環(huán)境數(shù)據(jù)上鏈方法只能由相應(yīng)的物聯(lián)網(wǎng)設(shè)備調(diào)用，訂單數(shù)據(jù)的上鏈方法由組織內(nèi)某一方用戶調(diào)用，本方案采用與身份認證相結(jié)合的方法實現(xiàn)權(quán)限控制機制。首先獲取調(diào)用者的證書信息，然后根據(jù)所調(diào)用的上鏈方法分類判斷。如果調(diào)用的是環(huán)境數(shù)據(jù)上鏈方法，驗證執(zhí)行此方法的用戶是否為物聯(lián)網(wǎng)設(shè)備，其次驗證該物聯(lián)網(wǎng)設(shè)備的MAC地址和證書中的MAC地址是否一致，如果全部驗證都過，則返回成功；如果調(diào)用的是發(fā)布訂單方法，判斷調(diào)用者是否為發(fā)貨商，如果驗證通過，則返回成功；如果調(diào)用的是確認訂單方法，判斷調(diào)用者是否為物流企業(yè)，如果驗證通過，則返回成功；如果調(diào)用的是簽收訂單方法，判斷調(diào)用者是否為收貨商，如果驗證通過，則返回成功；如果不是以上情況之一，則返回失敗。權(quán)限控制合約的算法流程如下所示：

算法1權(quán)限控制算法

輸入：要執(zhí)行的方法名稱（function），合約調(diào)用者的MAC地址（mac）。

輸出：如果權(quán)限驗證通過，則執(zhí)行具體的合約方法，否則結(jié)束訪問。

1.獲取合約調(diào)用者的證書信息

2.解析證書信息得到組織名稱certOrg，證書中的MAC地址certMac

3.IF function=="setEnvironmentData"THEN

4. IF certOrg=="sensor"&&certMAC==mac THEN

5.執(zhí)行setEnvironmentData（）方法

6.ELSE

7. break；

8. END IF

9.ELSE IF function=="issueOrder"且certOrg=="supply"THEN

10.執(zhí)行issueOrder（）方法；

11.ELSE

12. break；

13. END IF；

14.ELSE IF function=="confirmOrder"且certOrg=="supply"THEN

15.執(zhí)行confirmOrder（）方法；

16.ELSE

17. break；

18. END IF；

19.ELSE IF function=="signOrder"且certOrg=="supply"THEN

20.執(zhí)行signOrder（）方法；

21. ELSE

22. break；

23. END IF

24.END IF

6.2 訂單數(shù)據(jù)上鏈合約

訂單信息包括物流訂單號、發(fā)貨方姓名、發(fā)貨方地址、發(fā)貨方電話、收貨方姓名、收貨方地址、收貨方電話、貨物信息、物流公司確認信息、收貨方簽收信息、訂單狀態(tài)，其中貨物信息包括所運貨物的種類以及運輸所需的溫濕度范圍等數(shù)據(jù)，數(shù)據(jù)結(jié)構(gòu)定義，如表1所示。在數(shù)據(jù)存儲時，采用CouchDB作為狀態(tài)數(shù)據(jù)庫，將第一個字段即orderID作為key，其余各字段JSON序列化后作為value。

物流訂單在創(chuàng)建之后，將經(jīng)歷不同的狀態(tài)變化，其狀態(tài)標識由state字段表示，狀態(tài)轉(zhuǎn)移過程如圖6所示。

首先，發(fā)貨方將confirmID和signID字段置空，state字段標為NewPublish，其余各字段按照實際信息填寫完整，通過調(diào)用發(fā)布訂單合約方法將物流訂單信息發(fā)布到系統(tǒng)中，此時，訂單進入新發(fā)布狀態(tài)NewPublish。發(fā)布訂單的流程如下所示。

表1 訂單數(shù)據(jù)結(jié)構(gòu)

圖6 物流訂單狀態(tài)轉(zhuǎn)移圖

算法2發(fā)布訂單流程

輸入：由物流訂單號（orderID），發(fā)貨方姓名（sender），發(fā)貨方地址（senderAddress），發(fā)貨方電話（sendPhone），收貨方姓名（receiver），收貨方地址（receAddress），收貨方電話（recePhone），貨物信息（info）信息組成的json字符串a(chǎn)rgs。

輸出：如果訂單發(fā)布成功，返回成功標識；如果訂單發(fā)布不成功，返回錯誤信息。

1.將json字符串解析成訂單結(jié)構(gòu)體order；

2. orderAsBytes←GetState（order.OrderID）；

3.IF orderAsBytes不為空THEN

4.訂單已經(jīng)存在，不能發(fā)起訂單；

5.ELSE

6. err←PutState（order.OrderID，[]byte（args））；

7. IF err!=nil THEN

8.訂單提交錯誤，返回錯誤信息；

9. ELSE

10.訂單提交成功；

11. END IF

12.END IF

然后，物流公司在接收到發(fā)貨方的請求后，調(diào)用查詢訂單狀態(tài)方法查看訂單信息，如果確認接受此項訂單，則通過調(diào)用確認訂單方法填寫confirmID字段信息，并將state字段標為waitSign，此時進入物流運輸過程，訂單處于等待簽收狀態(tài)waitSign。其中，確認訂單的流程如下：

算法3確認訂單流程

輸入：物流訂單號（orderID），物流公司確認信息（confirmID）。

輸出：如果訂單確認成功，返回成功標識；如果訂單確認不成功，返回錯誤信息。

1. orderAsBytes←GetState（OrderID）；

2.IF orderAsBytes==nil THEN

3.訂單不存在，不能確認訂單；

4.ELSE

5.將訂單字節(jié)信息解析成結(jié)構(gòu)體order

6. order.confirmID←confirmID

7. order.state←waitSign

8. err←PutState（orderID，Marshal（order））

9. IF err!=nil THEN

10.訂單提交錯誤，返回錯誤信息；

11. ELSE

12.訂單提交成功；

13. END IF

14.END IF

最后，收貨方查看貨物后，可以通過調(diào)用簽收訂單方法選擇簽收訂單和拒絕簽收，如果簽收訂單，則填寫signID字段信息，并將state字段標記為EndSigned，訂單進入EndSigned狀態(tài)；如果拒絕簽收訂單，則直接將state字段標記為EndReject，訂單進入EndReject狀態(tài)。簽收訂單的過程如下所示：

算法4簽收訂單流程

輸入：物流訂單號（orderID），收貨方簽收信息（confirmID）。

輸出：如果訂單簽收成功，返回成功標識；如果訂單簽收不成功，返回錯誤信息。

1.orderAsBytes←GetState（OrderID）；

2.IF orderAsBytes==nil THEN

3.訂單不存在，不能簽收訂單；

4.ELSE

5.將訂單字節(jié)信息解析成結(jié)構(gòu)體order

6. IF簽收訂單THEN

7. order.confirmID←confirmID

8. order.state←EndSigned

9. ELSE IF拒絕簽收訂單THEN

10.order.confirmID←confirmID

11. order.state←EndReject

12. END

13. err ←PutState（orderID，Marshal（order））

14. IF err!=nil THEN

15.訂單簽收錯誤，返回錯誤信息；

16. ELSE

17.訂單簽收成功；

18. END IF

19.END IF

6.3 環(huán)境數(shù)據(jù)上鏈合約

環(huán)境數(shù)據(jù)的結(jié)構(gòu)如表2所示，物聯(lián)網(wǎng)設(shè)備執(zhí)行環(huán)境數(shù)據(jù)上鏈合約后，發(fā)貨方、收貨方、物流公司均可通過查詢鏈上數(shù)據(jù)實時查看環(huán)境數(shù)據(jù)信息，通過調(diào)用查看歷史數(shù)據(jù)的方法查看環(huán)境數(shù)據(jù)的歷史信息。

表2 環(huán)境信息數(shù)據(jù)結(jié)構(gòu)

7 方案測試

7.1 功能測試

本方案構(gòu)建了面向冷鏈物流的區(qū)塊鏈網(wǎng)絡(luò)模型，整個系統(tǒng)已經(jīng)在測試網(wǎng)中運行。整個區(qū)塊鏈網(wǎng)絡(luò)由七臺服務(wù)器構(gòu)成，其中四臺用于搭建Kafka集群，其余三臺作為三個組織的后臺服務(wù)器，每臺服務(wù)器和區(qū)塊鏈系統(tǒng)的配置如表3所示。

表3 測試環(huán)境配置信息

訂單數(shù)據(jù)上鏈與查詢的測試結(jié)果如圖7所示。其中圖7（a）表示發(fā)貨方發(fā)布訂單執(zhí)行后的結(jié)果以及通過訂單查詢可以看到訂單的狀態(tài)信息；圖7（b）表示物流企業(yè)確認訂單的執(zhí)行結(jié)果以后此時訂單信息；圖7（c）顯示了收貨方簽收物訂單的執(zhí)行結(jié)果和查詢的訂單信息。

環(huán)境數(shù)據(jù)上鏈與查詢的測試結(jié)果如圖8所示。

7.2 性能測試

本次性能測試主要研究每秒交易數(shù)量（TPS）的變化，測試時的主要固定參數(shù)如表4所示，圖9是通過改變并發(fā)數(shù)觀察每秒交易數(shù)量的變化，橫軸是單次并發(fā)數(shù)，縱軸是每秒交易數(shù)，測出的每秒交易數(shù)量最高是323。如圖10所示，用這種方法，經(jīng)過多次測試后，系統(tǒng)的每秒交易數(shù)量平均值為320，該性能可以滿足基本的業(yè)務(wù)需要。

圖7 訂單數(shù)據(jù)上鏈結(jié)果示意圖

圖8 環(huán)境數(shù)據(jù)上鏈結(jié)果示意圖

表4 測試環(huán)境配置信息

圖9 TPS與并發(fā)數(shù)關(guān)系圖

圖10 多次測試結(jié)果示意圖

通過測試分析可知，本系統(tǒng)通過了功能測試和性能測試，完成了預(yù)期設(shè)計目標，驗證了系統(tǒng)的可行性和有效性。本方案的優(yōu)勢主要體現(xiàn)在，和傳統(tǒng)中心化的冷鏈系統(tǒng)相比，構(gòu)建了以區(qū)塊鏈為底層的分布式存儲方案。利用區(qū)塊鏈技術(shù)的歷史數(shù)據(jù)不可篡改，很好地增進了各企業(yè)間的互信，擺脫了一家核心企業(yè)獨自掌握數(shù)據(jù)權(quán)限的情況。

8 結(jié)束語

本文將區(qū)塊鏈技術(shù)同物聯(lián)網(wǎng)技術(shù)相結(jié)合，提出了一種面向冷鏈物流行業(yè)的區(qū)塊鏈技術(shù)解決方案，通過引入消息隊列中間件，實現(xiàn)了異步調(diào)用合約，提高了數(shù)據(jù)上鏈的效率。同時，系統(tǒng)還會監(jiān)聽數(shù)據(jù)上鏈是否成功，由于超時等原因沒有上鏈的數(shù)據(jù)，將會進行二次上鏈，從而保證消息隊列里的數(shù)據(jù)都能完整的上鏈，即保證了數(shù)據(jù)的完整性，不會造成數(shù)據(jù)丟失。通過設(shè)計成員管理服務(wù)，保證了數(shù)據(jù)交易的安全性，即只有持有特定證書機構(gòu)簽發(fā)的數(shù)字證書的節(jié)點才能加入?yún)^(qū)塊鏈網(wǎng)絡(luò)。同時通過多通道機制，實現(xiàn)了數(shù)據(jù)隔離，保證只在每一次物流運輸過程的相關(guān)參與方之間共享數(shù)據(jù)。通過密鑰交換協(xié)議和對稱加密算法相結(jié)合的方案，訂單數(shù)據(jù)在傳輸過程中都進行了加密處理，保證了物流訂單傳輸?shù)陌踩?。通過將數(shù)字證書和物聯(lián)網(wǎng)設(shè)備的物理信息相關(guān)聯(lián)，保證只有相關(guān)的物聯(lián)網(wǎng)設(shè)備才能上傳數(shù)據(jù)。總之，區(qū)塊鏈技術(shù)和冷鏈物流領(lǐng)域的結(jié)合，必將會提高物流行業(yè)的互信，降低成本，提高安全性。

在2018年5月份，由普華永道和VeChain聯(lián)合發(fā)布的《2018年中國區(qū)塊鏈（非金融）應(yīng)用市場調(diào)查報告》中顯示，物流行業(yè)被業(yè)內(nèi)人士認為是除金融行業(yè)之外創(chuàng)新應(yīng)用價值最高的行業(yè)。冷鏈物流行業(yè)正在積極借鑒區(qū)塊鏈技術(shù)，助推其產(chǎn)業(yè)升級。比如，2018年5月，由京東物流主導(dǎo)，國內(nèi)首個“物流+區(qū)塊鏈技術(shù)應(yīng)用聯(lián)盟”成立，將區(qū)塊鏈與人工智能、物聯(lián)網(wǎng)相結(jié)合。本文是將區(qū)塊鏈技術(shù)應(yīng)用于冷鏈物流領(lǐng)域的初步探索，下一步將會同相關(guān)企業(yè)繼續(xù)完善該領(lǐng)域的應(yīng)用，提高系統(tǒng)性能，提供更多服務(wù)，進一步發(fā)掘區(qū)塊鏈在物流行業(yè)中的應(yīng)用價值。