張 森，葉 劍，李國(guó)剛

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

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

1 引言

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

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

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

2 相關(guān)工作

2.1 區(qū)塊鏈

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

根據(jù)實(shí)際應(yīng)用場(chǎng)景和需求，區(qū)塊鏈技術(shù)可以分為三種應(yīng)用模式，即公共鏈、聯(lián)盟鏈和私有鏈[19]。公共鏈?zhǔn)且员忍貛艦榇淼淖畛醯膮^(qū)塊鏈形態(tài)，任何節(jié)點(diǎn)都可以自由加入，并參與到賬本數(shù)據(jù)的讀寫、驗(yàn)證和共識(shí)，共同維護(hù)賬本數(shù)據(jù)；聯(lián)盟鏈?zhǔn)且环N有準(zhǔn)入控制機(jī)制的區(qū)塊鏈形態(tài)，適用于多個(gè)實(shí)體構(gòu)成的組織或者聯(lián)盟；私有鏈?zhǔn)且环N中心化的區(qū)塊鏈形態(tài)，完全由一個(gè)組織控制，適用于特定機(jī)構(gòu)的內(nèi)部數(shù)據(jù)管理和審計(jì)。

2.2 Hyperledger Fabric

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

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

2.3 Diffie-Hellman密鑰交換算法

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

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

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

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

（3）A計(jì)算k=Yxmod n。

（4）B計(jì)算k′=Xymod n。

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

3 方案整體設(shè)計(jì)

3.1 整體架構(gòu)

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

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

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

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

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

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

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

4 身份認(rèn)證

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

4.1 節(jié)點(diǎn)的身份認(rèn)證

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖4 加密傳輸模塊時(shí)序圖

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

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

Key1=client.computeSecret（serverPub）

COrder=Enc（order，key1）

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

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

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

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

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

步驟2將處理后的數(shù)據(jù)data存儲(chǔ)在本地?cái)?shù)據(jù)庫(kù)Redis中。

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

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

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

6 智能合約

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

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

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

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

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

輸出：如果權(quán)限驗(yà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ù)上鏈合約

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

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

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

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

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

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

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

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

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.訂單提交錯(cuò)誤，返回錯(cuò)誤信息；

9. ELSE

10.訂單提交成功；

11. END IF

12.END IF

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

算法3確認(rèn)訂單流程

輸入：物流訂單號(hào)（orderID），物流公司確認(rèn)信息（confirmID）。

輸出：如果訂單確認(rèn)成功，返回成功標(biāo)識(shí)；如果訂單確認(rèn)不成功，返回錯(cuò)誤信息。

1. orderAsBytes←GetState（OrderID）；

2.IF orderAsBytes==nil THEN

3.訂單不存在，不能確認(rèn)訂單；

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.訂單提交錯(cuò)誤，返回錯(cuò)誤信息；

11. ELSE

12.訂單提交成功；

13. END IF

14.END IF

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

算法4簽收訂單流程

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

輸出：如果訂單簽收成功，返回成功標(biāo)識(shí)；如果訂單簽收不成功，返回錯(cuò)誤信息。

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.訂單簽收錯(cuò)誤，返回錯(cuò)誤信息；

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ù)實(shí)時(shí)查看環(huán)境數(shù)據(jù)信息，通過調(diào)用查看歷史數(shù)據(jù)的方法查看環(huán)境數(shù)據(jù)的歷史信息。

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

7 方案測(cè)試

7.1 功能測(cè)試

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

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

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

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

7.2 性能測(cè)試

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

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

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

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

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

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

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

8 結(jié)束語(yǔ)

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

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