弋偉國(guó) 何建國(guó), 劉貴珊 康寧波

(1.寧夏大學(xué)物理與電子電氣工程學(xué)院， 銀川 750021； 2.寧夏大學(xué)食品與葡萄酒學(xué)院， 銀川 750021)

0 引言

果蔬供應(yīng)鏈往往涉及農(nóng)業(yè)種植企業(yè)、物流公司、監(jiān)管部門、消費(fèi)者等多個(gè)參與實(shí)體，追溯過(guò)程具有點(diǎn)多、線長(zhǎng)、面廣的特點(diǎn)[1]，追溯數(shù)據(jù)具有多源異構(gòu)的特點(diǎn)，過(guò)程復(fù)雜度高和數(shù)據(jù)耦合性強(qiáng)使果蔬質(zhì)量追溯體系的建立尤為困難。文獻(xiàn)[2]提出利用人工智能技術(shù)降低追溯過(guò)程斷鏈程度；文獻(xiàn)[3]提出通過(guò)區(qū)塊鏈技術(shù)重新構(gòu)建追溯體系，完成追溯信息的上鏈管理，形成農(nóng)產(chǎn)品供應(yīng)鏈聯(lián)盟系統(tǒng)內(nèi)的信息可溯源；文獻(xiàn)[4]提出的鏈上鏈下追溯信息雙存儲(chǔ)設(shè)計(jì)，降低區(qū)塊鏈數(shù)據(jù)存儲(chǔ)的負(fù)載。利用區(qū)塊鏈技術(shù)解決質(zhì)量追溯系統(tǒng)可信度低、鏈條不完整、存在信息孤島等問(wèn)題已成為業(yè)內(nèi)共識(shí)。

目前果蔬質(zhì)量追溯體系存在的問(wèn)題是各參與方對(duì)數(shù)據(jù)的信任度較低，供應(yīng)鏈各參與實(shí)體之間處于一種博弈關(guān)系，各個(gè)實(shí)體間信息不對(duì)稱，造成對(duì)追溯數(shù)據(jù)的信任度低和信任成本高[5]。傳統(tǒng)質(zhì)量追溯系統(tǒng)應(yīng)用中心化數(shù)據(jù)庫(kù)，追溯過(guò)程各個(gè)環(huán)節(jié)的數(shù)據(jù)由企業(yè)自主管理，存在信息丟失和被篡改的可能，產(chǎn)生糾紛時(shí)舉證困難、責(zé)任難以明確[6]，增強(qiáng)追溯數(shù)據(jù)的可信度是目前亟需解決的技術(shù)問(wèn)題[7]。

在增強(qiáng)追溯數(shù)據(jù)的可信度研究方面，一些學(xué)者進(jìn)行了研究[8-12]，近些年來(lái)針對(duì)質(zhì)量追溯數(shù)據(jù)可信度增強(qiáng)方法研究主要集中在通過(guò)物聯(lián)網(wǎng)數(shù)據(jù)采集設(shè)備減少數(shù)據(jù)采集環(huán)節(jié)的人為干預(yù)，通過(guò)非對(duì)稱加密算法防止數(shù)據(jù)傳輸過(guò)程篡改，在數(shù)據(jù)存儲(chǔ)和處理端采用分布式系統(tǒng)多節(jié)點(diǎn)共同驗(yàn)證來(lái)保證數(shù)據(jù)真實(shí)性。隨著區(qū)塊鏈技術(shù)的發(fā)展，利用區(qū)塊鏈天然的數(shù)據(jù)不可偽造篡改能力保證質(zhì)量追溯系統(tǒng)數(shù)據(jù)可信度的研究越來(lái)越多，但是區(qū)塊鏈平臺(tái)數(shù)據(jù)讀取速度慢的特點(diǎn)使其應(yīng)用在果蔬質(zhì)量追溯這種需要大量讀取數(shù)據(jù)的系統(tǒng)時(shí)往往受到限制，因此需要結(jié)合實(shí)際應(yīng)用特點(diǎn)研究保證數(shù)據(jù)可信并提高數(shù)據(jù)讀取效率的解決策略[13-18]。

本文針對(duì)果蔬質(zhì)量追溯系統(tǒng)數(shù)據(jù)可信度低的問(wèn)題，將區(qū)塊鏈技術(shù)應(yīng)用到果蔬質(zhì)量追溯系統(tǒng)，利用二次上鏈方法提高查詢效率，通過(guò)試驗(yàn)驗(yàn)證并應(yīng)用到果蔬質(zhì)量追溯系統(tǒng)中，研究提升果蔬質(zhì)量追溯系統(tǒng)可信度和提高果蔬質(zhì)量追溯查詢效率的方法。

1 可信追溯方法研究

1.1 追溯流程

將果蔬質(zhì)量追溯從供應(yīng)鏈角度劃分為種植、倉(cāng)儲(chǔ)、物流和銷售環(huán)節(jié)。種植環(huán)節(jié)包括播種、施肥、除草、澆水、收割、采摘等作業(yè)，需具備記錄產(chǎn)地信息、田地環(huán)境變量、作業(yè)時(shí)間、作業(yè)人員、農(nóng)資信息、完成進(jìn)度、作業(yè)照片等功能；倉(cāng)儲(chǔ)環(huán)節(jié)需記錄果蔬入庫(kù)時(shí)間、出庫(kù)時(shí)間、冷庫(kù)溫濕度；物流環(huán)節(jié)需記錄果蔬打包上車時(shí)間、物流過(guò)程物流車GPS定位和冷鏈溫濕度；銷售環(huán)節(jié)能夠記錄果蔬銷售城市和分銷地點(diǎn)。

如圖1所示，從追溯流程角度要實(shí)現(xiàn)正向查詢和反向追溯，消費(fèi)者通過(guò)掃描果蔬包裝上的二維碼能夠查詢果蔬從種植到銷售的可視化數(shù)據(jù)并對(duì)產(chǎn)品進(jìn)行評(píng)價(jià)和投訴，在果蔬出現(xiàn)質(zhì)量問(wèn)題時(shí)監(jiān)管部門和供應(yīng)鏈參與機(jī)構(gòu)能夠反向追溯導(dǎo)致果蔬質(zhì)量問(wèn)題的環(huán)節(jié)和因素；從數(shù)據(jù)可信角度供應(yīng)鏈參與實(shí)體能夠提交數(shù)據(jù)，并能夠保證提交的數(shù)據(jù)是多方可信的。果蔬在進(jìn)入銷售環(huán)節(jié)追溯鏈形成后追溯數(shù)據(jù)基本確定，此時(shí)如果完成數(shù)據(jù)可信驗(yàn)證將會(huì)大大減少消費(fèi)者查詢用時(shí)，提高系統(tǒng)響應(yīng)速度。

圖1 查詢和追溯過(guò)程Fig.1 Query and trace process

1.2 數(shù)據(jù)存儲(chǔ)與驗(yàn)證方法

質(zhì)量追溯系統(tǒng)中的數(shù)據(jù)是實(shí)時(shí)產(chǎn)生的，田間氣象站和冷庫(kù)及物流車上安裝的感知設(shè)備產(chǎn)生的數(shù)據(jù)是基于時(shí)間序列的，這些數(shù)據(jù)需要實(shí)時(shí)存儲(chǔ)，如果將完整數(shù)據(jù)直接存儲(chǔ)在區(qū)塊鏈系統(tǒng)中會(huì)造成系統(tǒng)阻塞?？梢圆捎谩皵?shù)據(jù)入庫(kù)+哈希值上鏈”的方式，保存數(shù)據(jù)時(shí)將原始數(shù)據(jù)存儲(chǔ)在數(shù)據(jù)庫(kù)中，將原始數(shù)據(jù)的哈希值添加到區(qū)塊鏈上；讀取數(shù)據(jù)時(shí)先讀取數(shù)據(jù)庫(kù)中的數(shù)據(jù)并計(jì)算哈希值，然后從區(qū)塊鏈中查詢?cè)摂?shù)據(jù)的哈希值，將計(jì)算的哈希值與區(qū)塊鏈上的哈希值進(jìn)行比對(duì)，即可驗(yàn)證數(shù)據(jù)是否被篡改。

“數(shù)據(jù)入庫(kù)+哈希值上鏈”的方法在數(shù)據(jù)量小且對(duì)響應(yīng)時(shí)間要求不高的情況下能夠滿足要求，但是果蔬質(zhì)量追溯系統(tǒng)需要追溯果蔬全生命周期的所有數(shù)據(jù)，消費(fèi)者進(jìn)行一次追溯查詢操作涉及農(nóng)田環(huán)境、種植作業(yè)、倉(cāng)儲(chǔ)和物流等多個(gè)環(huán)節(jié)，需要查詢多條記錄。從區(qū)塊鏈獲取哈希值進(jìn)行比對(duì)驗(yàn)證非常消耗系統(tǒng)資源和時(shí)間，尤其在消費(fèi)者追溯環(huán)節(jié)對(duì)系統(tǒng)響應(yīng)時(shí)間極高，系統(tǒng)延時(shí)會(huì)嚴(yán)重影響到用戶使用體驗(yàn)。

本文在“數(shù)據(jù)入庫(kù)+哈希值上鏈”方法的基礎(chǔ)上通過(guò)數(shù)據(jù)哈希值二次上鏈和驗(yàn)證進(jìn)行了改進(jìn)。具體步驟為：

(1)數(shù)據(jù)保存。數(shù)據(jù)保存到數(shù)據(jù)庫(kù)后計(jì)算數(shù)據(jù)哈希值，并將哈希值添加到區(qū)塊鏈，完成第1次上鏈；在這個(gè)步驟中，數(shù)據(jù)輸入可異步完成，無(wú)需用戶或感知設(shè)備等待，對(duì)響應(yīng)時(shí)間要求低，計(jì)算哈希值并添加到區(qū)塊鏈中造成的等待時(shí)間對(duì)系統(tǒng)性能影響較小。

(2)提前驗(yàn)證并將數(shù)據(jù)打包上鏈。在果蔬銷售環(huán)節(jié)追溯流程結(jié)束后追溯鏈形成，追溯數(shù)據(jù)已確定，追溯鏈相關(guān)數(shù)據(jù)在步驟(1)中已全部添加到數(shù)據(jù)庫(kù)和區(qū)塊鏈中。系統(tǒng)自動(dòng)讀取追溯鏈涉及的所有數(shù)據(jù)，并與區(qū)塊鏈上的數(shù)據(jù)比對(duì)驗(yàn)證數(shù)據(jù)是否被篡改，完成第1次驗(yàn)證，驗(yàn)證結(jié)束后對(duì)所有數(shù)據(jù)打包后再次計(jì)算哈希值h1，并把哈希值h1添加到區(qū)塊鏈，完成第2次上鏈。

(3)數(shù)據(jù)追溯。從數(shù)據(jù)庫(kù)讀取本次追溯涉及的所有數(shù)據(jù)，打包計(jì)算數(shù)據(jù)哈希值h2，再?gòu)膮^(qū)塊鏈獲取數(shù)據(jù)哈希值h1，對(duì)比h1和h2是否相等即可驗(yàn)證數(shù)據(jù)的真實(shí)性，完成第2次驗(yàn)證。這個(gè)步驟中追溯果蔬質(zhì)量相關(guān)數(shù)據(jù)時(shí)，用戶處于等待狀態(tài)，對(duì)系統(tǒng)響應(yīng)時(shí)間要求高，需要較快的數(shù)據(jù)查詢速度。

1.3 理論分析

1.3.1數(shù)據(jù)可信度

數(shù)據(jù)在存儲(chǔ)環(huán)節(jié)的不可篡改性是數(shù)據(jù)可信的重要基礎(chǔ)，在數(shù)據(jù)存儲(chǔ)到數(shù)據(jù)庫(kù)之前利用MD5算法計(jì)算數(shù)據(jù)哈希值，在追溯鏈形成后把追溯鏈中涉及的數(shù)據(jù)和哈希值逐條驗(yàn)證，通過(guò)后將所有數(shù)據(jù)打包再利用MD5算法計(jì)算數(shù)據(jù)哈希值。

MD5算法將數(shù)據(jù)按512位為1組進(jìn)行分組，分組后又劃分為16個(gè)32位子分組。對(duì)于每個(gè)子分組的計(jì)算由4圈組成，每圈有16步，每圈的運(yùn)算中包括4個(gè)非線性函數(shù)，即

(1)

算法的最終輸出由4個(gè)32位分組組成，將這4個(gè)32位分組級(jí)聯(lián)后生成一個(gè)128位散列值為最終結(jié)果[19]。從算法過(guò)程和非線性函數(shù)可以看出MD5算法是對(duì)原始數(shù)據(jù)的有損壓縮計(jì)算，無(wú)論原始數(shù)據(jù)多長(zhǎng)都會(huì)生成一個(gè)長(zhǎng)度為128位的哈希值。

有研究表明通過(guò)一定的碰撞試驗(yàn)可以產(chǎn)生相同哈希值的原數(shù)據(jù)[20]，但是本文通過(guò)兩次哈希值計(jì)算并且數(shù)據(jù)具有一定的實(shí)際意義和特定的數(shù)據(jù)格式，通過(guò)碰撞產(chǎn)生的原始數(shù)據(jù)是隨機(jī)的，經(jīng)過(guò)程序的格式檢測(cè)即可判斷出真?zhèn)巍?/p>

以上分析證明了通過(guò)把數(shù)據(jù)哈希值存儲(chǔ)在區(qū)塊鏈，原始數(shù)據(jù)存儲(chǔ)在數(shù)據(jù)庫(kù)，無(wú)法在哈希值不變的情況下修改原始數(shù)據(jù)，但是篡改原始數(shù)據(jù)的同時(shí)修改對(duì)應(yīng)的哈希值可以實(shí)現(xiàn)數(shù)據(jù)篡改，下面將分析如何保證哈希值的不可篡改。

在區(qū)塊鏈系統(tǒng)中每個(gè)哈希值生成一個(gè)數(shù)據(jù)區(qū)塊[21]，如圖2所示每個(gè)數(shù)據(jù)區(qū)塊包含區(qū)塊頭和區(qū)塊體兩部分：區(qū)塊頭封裝了前一區(qū)塊哈希值、當(dāng)前區(qū)塊的哈希值、當(dāng)前區(qū)塊隨機(jī)數(shù)、Merkle根以及時(shí)間戳等信息[22]；區(qū)塊體包括當(dāng)前區(qū)塊的交易以及經(jīng)過(guò)驗(yàn)證的區(qū)塊創(chuàng)建過(guò)程中生成的所有交易記錄，對(duì)于本文來(lái)說(shuō)交易記錄就是原始數(shù)據(jù)的哈希值，這些記錄最終生成唯一的Merkle根記入?yún)^(qū)塊頭[23]。通過(guò)每個(gè)區(qū)塊存儲(chǔ)前一個(gè)區(qū)塊的哈希值使區(qū)塊首尾相連形成區(qū)塊鏈，當(dāng)區(qū)塊鏈中任意區(qū)塊的信息被篡改則所有區(qū)塊的哈希值必然發(fā)生改變，以此來(lái)保證區(qū)塊鏈上數(shù)據(jù)不可篡改。

圖2 區(qū)塊結(jié)構(gòu)圖Fig.2 Structure diagram of block

1.3.2存儲(chǔ)效率

普通方法在追溯查詢環(huán)節(jié)需要從區(qū)塊鏈讀取追溯相關(guān)數(shù)據(jù)的哈希值并從數(shù)據(jù)庫(kù)中讀取相關(guān)數(shù)據(jù)逐條計(jì)算哈希值，改進(jìn)后的方法只需從區(qū)塊鏈讀取一次哈希值后從數(shù)據(jù)庫(kù)讀取所有相關(guān)數(shù)據(jù)并打包計(jì)算哈希值對(duì)比驗(yàn)證，兩種方法的用時(shí)計(jì)算公式為

(2)

式中T1——普通方法用時(shí)

T2——改進(jìn)后的方法用時(shí)

n——數(shù)據(jù)哈希值個(gè)數(shù)

t1——從區(qū)塊鏈讀取一條數(shù)據(jù)哈希值用時(shí)

t2——從數(shù)據(jù)庫(kù)關(guān)聯(lián)查詢多條數(shù)據(jù)用時(shí)

通過(guò)式(2)可以看出普通方法算法時(shí)間復(fù)雜度為O(n)，改進(jìn)后的方法算法時(shí)間復(fù)雜度為O(1)，理論上可近似認(rèn)為改進(jìn)后的方法與普通方法相比算法時(shí)間復(fù)雜度由線性階降低為常數(shù)階，數(shù)據(jù)查詢效率明顯提升。

1.4 試驗(yàn)與結(jié)果分析

對(duì)1.2節(jié)中提出的兩種方法，將“數(shù)據(jù)入庫(kù)+哈希值上鏈”方法稱為普通方法，將基于“數(shù)據(jù)入庫(kù)+哈希值上鏈”的哈希值二次上鏈和驗(yàn)證方法稱為改進(jìn)方法。改進(jìn)方法在數(shù)據(jù)保存環(huán)節(jié)數(shù)據(jù)打包計(jì)算哈希值后添加到區(qū)塊鏈操作本應(yīng)該在果蔬進(jìn)入銷售環(huán)節(jié)后執(zhí)行，但是在試驗(yàn)中為了便于對(duì)比數(shù)據(jù)且減小人為因素對(duì)試驗(yàn)的干預(yù)，將此環(huán)節(jié)放在數(shù)據(jù)上傳完成后進(jìn)行。試驗(yàn)步驟如圖3所示。

圖3 普通方法和改進(jìn)方法試驗(yàn)流程圖Fig.3 Test flow charts of common method and improved method

試驗(yàn)在阿里云服務(wù)器中進(jìn)行，服務(wù)器CPU為單核、內(nèi)存為2 GB，操作系統(tǒng)為Ubuntu 20.04 64位、網(wǎng)絡(luò)帶寬為2 Mb/s，F(xiàn)abric版本為2.0，Docker 版本為20.10.8。Fabric 聯(lián)盟網(wǎng)絡(luò)包括4個(gè)Peer節(jié)點(diǎn)，1個(gè)Orderer節(jié)點(diǎn)，F(xiàn)abric中的數(shù)據(jù)庫(kù)采用CouchDB，共識(shí)機(jī)制采用Kafka，試驗(yàn)用例基于fabric-gateway-java V2.2.2開(kāi)發(fā)，Chaincode采用Node.js編寫。

1.4.1數(shù)據(jù)可信度

在數(shù)據(jù)完成入庫(kù)和上鏈后，利用Webyog SQLyog數(shù)據(jù)庫(kù)客戶端工具登錄數(shù)據(jù)庫(kù)管理系統(tǒng)隨機(jī)修改50個(gè)追溯鏈中的其中1條數(shù)據(jù)，修改數(shù)據(jù)后再通過(guò)追溯查詢客戶端查詢50個(gè)追溯鏈的結(jié)果，均顯示數(shù)據(jù)已被篡改。

1.4.2數(shù)據(jù)保存和查詢效率

為了保證試驗(yàn)的準(zhǔn)確性，每組數(shù)據(jù)經(jīng)過(guò)圖3流程重復(fù)操作20次，計(jì)算20次平均值作為最終結(jié)果，針對(duì)兩種方法分別進(jìn)行試驗(yàn)。

如圖4所示，改進(jìn)方法數(shù)據(jù)保存用時(shí)比普通方法增加4%左右，主要由于改進(jìn)方法多了數(shù)據(jù)逐條驗(yàn)證后打包計(jì)算哈希值并添加到區(qū)塊鏈環(huán)節(jié)，由于數(shù)據(jù)保存屬于異步操作無(wú)需用戶等待，用時(shí)增加4%左右對(duì)系統(tǒng)影響很??；如圖5所示，改進(jìn)方法在數(shù)據(jù)查詢平均用時(shí)0.066 s，而普通方法用時(shí)隨著數(shù)據(jù)條數(shù)增加呈線性增加，在數(shù)據(jù)條數(shù)為300時(shí)改進(jìn)方法查詢用時(shí)為普通方法的0.29%。

圖4 普通方法和改進(jìn)方法在不同數(shù)據(jù)條數(shù)下保存數(shù)據(jù)時(shí)間對(duì)比Fig.4 Comparison of data saving time of common method and improved method under different data pieces

圖5 普通方法和改進(jìn)方法在不同數(shù)據(jù)條數(shù)下查詢數(shù)據(jù)時(shí)間對(duì)比Fig.5 Comparison of data query time of common method and improved method under different data pieces

2 系統(tǒng)實(shí)現(xiàn)

2.1 相關(guān)技術(shù)

系統(tǒng)實(shí)現(xiàn)涉及的編程語(yǔ)言、環(huán)境、技術(shù)框架、底層架構(gòu)及工具有Java、JavaScript、Node.js、Spring、SpringMVC、MyBatis、Express、Hyperledger Fabric、MySql、Maven、Tomcat、Git等；從功能上可將系統(tǒng)分為管理平臺(tái)、數(shù)據(jù)平臺(tái)和追溯客戶端3個(gè)子系統(tǒng)，追溯系統(tǒng)管理平臺(tái)和數(shù)據(jù)平臺(tái)服務(wù)端開(kāi)發(fā)語(yǔ)言采用Java，使用Spring、SpringMVC、MyBatis(經(jīng)典的SSM框架)分別作為軟件系統(tǒng)的 IoC和AOP容器、MVC 架構(gòu)、數(shù)據(jù)持久化工具，瀏覽器端采用HTML、JavaScript、CSS等前端編程語(yǔ)言實(shí)現(xiàn)，項(xiàng)目構(gòu)建采用Maven，Web容器采用Tomcat；追溯客戶端服務(wù)端采用Node.js語(yǔ)言開(kāi)發(fā)，使用Express框架，追溯客戶端之所以采用基于Node.js環(huán)境開(kāi)發(fā)而沒(méi)有采用Java，主要是因?yàn)樽匪菘蛻舳撕蠖藰I(yè)務(wù)相對(duì)簡(jiǎn)單，主要是數(shù)據(jù)渲染，對(duì)系統(tǒng)響應(yīng)時(shí)間要求較高，Node.js以非阻塞方式處理輸入/輸出，這意味著單個(gè)線程可以同時(shí)管理多個(gè)輸入/輸出請(qǐng)求，無(wú)需等待一個(gè)請(qǐng)求完成即可開(kāi)始處理其他請(qǐng)求，響應(yīng)速度較快；3個(gè)子系統(tǒng)的數(shù)據(jù)存儲(chǔ)數(shù)據(jù)庫(kù)選用MySql，區(qū)塊鏈平臺(tái)選用Hyperledger Fabric。

2.2 系統(tǒng)開(kāi)發(fā)

2.2.1區(qū)塊鏈搭建

Fabric系統(tǒng)分為種植機(jī)構(gòu)、倉(cāng)儲(chǔ)機(jī)構(gòu)、物流機(jī)構(gòu)和監(jiān)管部門4個(gè)組織，每個(gè)組織內(nèi)都包含承擔(dān)不同功能的Peer節(jié)點(diǎn)。如圖6所示，每個(gè)組織都有各自對(duì)應(yīng)的Fabric-ca服務(wù)器負(fù)責(zé)動(dòng)態(tài)生成Fabric的賬號(hào)，Committer Peer接收生成的交易區(qū)塊，Leader Peer負(fù)責(zé)將交易從排序節(jié)點(diǎn)分發(fā)到組織中的其他節(jié)點(diǎn)，Endorse Peer在滿足背書策略的條件下對(duì)交易進(jìn)行確認(rèn)，Anchor Peer負(fù)責(zé)與其他組織中的節(jié)點(diǎn)進(jìn)行通信，所有的組織共用一個(gè)統(tǒng)一的Orderer集群，Kafka是一個(gè)分布式消息隊(duì)列系統(tǒng)，負(fù)責(zé)打包數(shù)據(jù)。

圖6 Fabric系統(tǒng)結(jié)構(gòu)圖Fig.6 Fabric system structure diagram

每個(gè)參與方都可以向Fabric系統(tǒng)中添加數(shù)據(jù)，并通過(guò)Gossip廣播協(xié)議同步到其他節(jié)點(diǎn)，當(dāng)一個(gè)節(jié)點(diǎn)接收到交易信息后，隨機(jī)選擇x個(gè)節(jié)點(diǎn)同步消息，節(jié)點(diǎn)收到信息后，更新數(shù)據(jù)，這樣使得每個(gè)節(jié)點(diǎn)都能維持完整的鏈上數(shù)據(jù)，且不需要節(jié)點(diǎn)時(shí)刻處于連接狀態(tài)，還能處理節(jié)點(diǎn)故障和拜占庭問(wèn)題[24]。

2.2.2硬件系統(tǒng)搭建

在農(nóng)田安裝氣象環(huán)境監(jiān)測(cè)站感知農(nóng)田環(huán)境因子。氣象站由數(shù)據(jù)采集器、環(huán)境傳感器、視頻監(jiān)控系統(tǒng)、物聯(lián)網(wǎng)數(shù)據(jù)傳輸模塊組成，主機(jī)電源供電方式采用戶外太陽(yáng)能供電和內(nèi)置鋰電池組供電，數(shù)據(jù)采集模塊采用MODBUS485通信，自動(dòng)識(shí)別各類型支持485通信的傳感器，最多可采集256個(gè)傳感器數(shù)據(jù)，目前可采集空氣溫度、露點(diǎn)溫度、空氣濕度、光照強(qiáng)度、大氣壓力、風(fēng)速、風(fēng)力、風(fēng)向、降水量、土壤溫度和土壤濕度。主機(jī)采取的多種遠(yuǎn)程數(shù)據(jù)傳輸方式，能夠通過(guò)以太網(wǎng)、WiFi或4G網(wǎng)絡(luò)將數(shù)據(jù)實(shí)時(shí)傳輸?shù)綌?shù)據(jù)平臺(tái)。

2.2.3軟件系統(tǒng)開(kāi)發(fā)

圖7 果蔬質(zhì)量追溯管理平臺(tái)部分界面Fig.7 Partial interface of fruit and vegetable quality traceability platform

管理系統(tǒng)部分工作界面如圖7所示，用戶角色分為系統(tǒng)管理員和業(yè)務(wù)管理員，系統(tǒng)管理員是負(fù)責(zé)維護(hù)系統(tǒng)的工作人員，具有最高權(quán)限，業(yè)務(wù)管理員是種植機(jī)構(gòu)、倉(cāng)儲(chǔ)機(jī)構(gòu)、物流機(jī)構(gòu)和監(jiān)管部門工作人員；管理員可在企業(yè)管理界面根據(jù)業(yè)務(wù)實(shí)際需要添加企業(yè)，消費(fèi)者可以通過(guò)掃描追溯碼查看企業(yè)名稱、描述、地點(diǎn)和照片；使用氣象站、冷庫(kù)和物流車感知設(shè)備之前需由業(yè)務(wù)管理員將設(shè)備信息添加到系統(tǒng)中，包括設(shè)備名稱、設(shè)備類型、支持的網(wǎng)絡(luò)類型、通信協(xié)議、硬件ID；果蔬存在一年收獲多茬的情況，批次管理為了區(qū)分同一塊農(nóng)田種植的多茬果蔬，在果蔬種植前種植機(jī)構(gòu)管理員需在系統(tǒng)中添加批次。

圖8為氣象站檢測(cè)農(nóng)田光照強(qiáng)度的曲線圖，另外還可檢測(cè)空氣溫濕度、露點(diǎn)溫度、大氣壓力、風(fēng)速、降水量、土壤溫濕度、冷庫(kù)和物流車門開(kāi)關(guān)狀態(tài)、物流車GPS位置等信息，針對(duì)每個(gè)指標(biāo)可以設(shè)置預(yù)警值，當(dāng)達(dá)到預(yù)警值時(shí)會(huì)通過(guò)短信將預(yù)警信息推送給管理人員。

消費(fèi)者追溯客戶端界面如圖9所示，消費(fèi)者可以通過(guò)掃描包裝上的二維碼查詢果蔬種植企業(yè)信息、企業(yè)位置、種植過(guò)程、物流信息、農(nóng)田環(huán)境信息、冷庫(kù)溫濕度和物流車溫濕度，并能對(duì)果蔬進(jìn)行評(píng)價(jià)和投訴。

圖8 物聯(lián)網(wǎng)平臺(tái)數(shù)據(jù)檢測(cè)曲線Fig.8 Data detection curve of Internet of things platform

圖9 追溯客戶端界面Fig.9 Traceability client interface

圖10 數(shù)據(jù)驗(yàn)證頁(yè)面Fig.10 Data validation interface

如圖10所示，消費(fèi)者在數(shù)據(jù)驗(yàn)證界面可以從數(shù)據(jù)庫(kù)中獲取本次追溯查詢的所有原始數(shù)據(jù)，從區(qū)塊鏈中獲取本次追溯查詢的哈希值，該頁(yè)面還可以計(jì)算原始數(shù)據(jù)的哈希值，消費(fèi)者通過(guò)計(jì)算原始數(shù)據(jù)哈希值后與從區(qū)塊鏈獲取的哈希值比較，如果相等則說(shuō)明原始數(shù)據(jù)未被篡改，如不同則說(shuō)明數(shù)據(jù)被篡改。

2.3 應(yīng)用與示范

將本文研究的系統(tǒng)應(yīng)用在寧夏鑫茂祥現(xiàn)代農(nóng)業(yè)發(fā)展有限公司，該企業(yè)主要從事寧夏回族自治區(qū)供港菜心和芥藍(lán)的生產(chǎn)，其兩家子公司從事供港蔬菜的貯藏和運(yùn)輸。本文研究的果蔬質(zhì)量追溯系統(tǒng)有效地提高了供港蔬菜的品牌效益，起到了質(zhì)量控制效果。

3 結(jié)論

(1)基于區(qū)塊鏈的數(shù)據(jù)哈希值二次上鏈和驗(yàn)證方法增強(qiáng)了果蔬質(zhì)量追溯系統(tǒng)數(shù)據(jù)存儲(chǔ)可信度，能夠保證質(zhì)量追溯多個(gè)參與實(shí)體之間數(shù)據(jù)的真實(shí)性，同時(shí)解決了區(qū)塊鏈存儲(chǔ)果蔬質(zhì)量追溯數(shù)據(jù)時(shí)消費(fèi)者追溯查詢用時(shí)過(guò)長(zhǎng)問(wèn)題，追溯查詢算法時(shí)間復(fù)雜度由線性階降低為常數(shù)階，消費(fèi)者追溯查詢用時(shí)控制在0.066 s左右，在數(shù)量條數(shù)為300時(shí)，查詢用時(shí)是普通方法的0.29%，隨著數(shù)據(jù)條數(shù)的增加查詢時(shí)間基本保持不變。

(2)基于Hyperledger Fabric平臺(tái)，采用Kafka共識(shí)機(jī)制，使用JavaWeb、Node.js等技術(shù)開(kāi)發(fā)質(zhì)量追溯系統(tǒng)具有很高的可行性，本文的實(shí)現(xiàn)方案和技術(shù)細(xì)節(jié)為開(kāi)發(fā)區(qū)塊鏈相關(guān)應(yīng)用提供了方案設(shè)計(jì)和技術(shù)實(shí)現(xiàn)方面的參考依據(jù)。