基于聯(lián)盟區(qū)塊鏈的進(jìn)口農(nóng)產(chǎn)品溯源系統(tǒng)研究

應(yīng) 毅， 王志瑞， 劉亞軍， 任 凱

(1.三江學(xué)院計(jì)算機(jī)科學(xué)與工程學(xué)院，江蘇南京 210012； 2.東南大學(xué)計(jì)算機(jī)科學(xué)與工程學(xué)院，江蘇南京 210096；3.南京工業(yè)大學(xué)浦江學(xué)院，江蘇南京 211200)

1 研究現(xiàn)狀和相關(guān)技術(shù)

1.1 傳統(tǒng)的農(nóng)產(chǎn)品溯源信息化技術(shù)

農(nóng)產(chǎn)品溯源體系以生產(chǎn)、加工、倉儲(chǔ)、運(yùn)輸、銷售等流程為主線，記錄和管理從田間到餐桌所有環(huán)節(jié)的產(chǎn)品信息。溯源體系涉及3類主體，第1類是產(chǎn)品質(zhì)量的監(jiān)管機(jī)構(gòu)，包括各級(jí)市場監(jiān)督管理局、各級(jí)衛(wèi)生健康委員會(huì)；第2類是產(chǎn)業(yè)鏈相關(guān)企業(yè)，包括生產(chǎn)商、加工商、物流服務(wù)商、分銷商、零售商等；第3類是末端消費(fèi)者。

建立農(nóng)產(chǎn)品溯源系統(tǒng)是對(duì)產(chǎn)品質(zhì)量監(jiān)督與控制行之有效的技術(shù)手段，一旦發(fā)生質(zhì)量安全問題，通過各種信息化方法能夠快速追溯到產(chǎn)品的來源和流通途徑，定位責(zé)任主體，及時(shí)召回有問題產(chǎn)品。傳統(tǒng)的農(nóng)產(chǎn)品溯源系統(tǒng)是以中心數(shù)據(jù)庫為基礎(chǔ)，結(jié)合軟件開發(fā)技術(shù)、網(wǎng)絡(luò)通信技術(shù)、物聯(lián)網(wǎng)技術(shù)構(gòu)建的管理信息系統(tǒng)。產(chǎn)業(yè)鏈企業(yè)提交產(chǎn)品信息至溯源系統(tǒng)；質(zhì)量監(jiān)管部門調(diào)取產(chǎn)品信息監(jiān)督質(zhì)量安全；消費(fèi)者查詢溯源系統(tǒng)獲取產(chǎn)品溯源信息(圖1)。

無論是由政府主導(dǎo)，還是第三方承建，在傳統(tǒng)的農(nóng)產(chǎn)品溯源系統(tǒng)中，依賴單一中心數(shù)據(jù)庫的數(shù)據(jù)存儲(chǔ)方式都存在數(shù)據(jù)安全問題，無法從技術(shù)層面完全杜絕編造、篡改數(shù)據(jù)的可能。產(chǎn)業(yè)鏈上下游主體處于復(fù)雜的博弈關(guān)系中，在彼此無法完全信任的情況下，在產(chǎn)生糾紛時(shí)容易出現(xiàn)質(zhì)疑溯源信息真實(shí)性的局面，進(jìn)而舉證困難，難以明確責(zé)任。與傳統(tǒng)的溯源鏈條稍有不同，在進(jìn)口農(nóng)產(chǎn)品的溯源體系中，處在產(chǎn)業(yè)鏈上游的產(chǎn)品供應(yīng)商通常是境外企業(yè)，它們與產(chǎn)業(yè)鏈上的其他主體之間僅僅是商業(yè)合作關(guān)系，而不是隸屬關(guān)系。鑒于利益訴求不同，此類主體顧忌的不僅僅是硬件損壞、黑客入侵、數(shù)據(jù)丟失等意外情況，更多的是監(jiān)守自盜的發(fā)生。

區(qū)塊鏈技術(shù)具有非集中化、不可篡改、可追溯、高可信、高可用等特點(diǎn)，為構(gòu)建非互信環(huán)境下的數(shù)據(jù)共享系統(tǒng)提供了新思路。將其應(yīng)用于溯源系統(tǒng)中，可從技術(shù)層面保證溯源信息的真實(shí)性，提升溯源流程的透明度和可信度，有效保障“政府-企業(yè)-消費(fèi)者”三方利益。

1.2 區(qū)塊鏈技術(shù)

區(qū)塊鏈技術(shù)起源于一篇署名“中本聰”所撰寫的著名論文《Bitcoin：a peer-to-peer electronic cash system》，并以此為理論基礎(chǔ)，實(shí)現(xiàn)了一種構(gòu)筑在對(duì)等網(wǎng)絡(luò)上又無需任何金融機(jī)構(gòu)背書的數(shù)字貨幣和電子支付系統(tǒng)。經(jīng)過近10年的發(fā)展，區(qū)塊鏈技術(shù)逐步獨(dú)立于比特幣，宏觀上看，它是利用加密鏈?zhǔn)絽^(qū)塊結(jié)構(gòu)來驗(yàn)證與存儲(chǔ)數(shù)據(jù)、利用分布式節(jié)點(diǎn)共識(shí)算法來生成和更新數(shù)據(jù)、利用自動(dòng)化腳本代碼(智能合約)來編程和操作數(shù)據(jù)的一種全新的非集中化基礎(chǔ)架構(gòu)與分布式計(jì)算范式。在經(jīng)歷了區(qū)塊鏈1.0“數(shù)字貨幣”、區(qū)塊鏈2.0“數(shù)字金融”2個(gè)階段后，區(qū)塊鏈3.0“商業(yè)區(qū)塊鏈”呈現(xiàn)出非集中化與集體維護(hù)、不可篡改與可追溯性、高可信、高可用等4個(gè)方面的技術(shù)價(jià)值。

根據(jù)節(jié)點(diǎn)參與方式和應(yīng)用場景的不同，區(qū)塊鏈又分為公有鏈和許可鏈。為了實(shí)現(xiàn)分布式數(shù)據(jù)的一致性，區(qū)塊鏈的事務(wù)處理能力和區(qū)塊生成速度是有限的。比特幣是典型的公有鏈，任何節(jié)點(diǎn)都可以自由參與，并需要一個(gè)激勵(lì)機(jī)制(挖礦)，造成節(jié)點(diǎn)眾多、效率低下，比特幣網(wǎng)絡(luò)的交易速度大約只有7筆/秒。私有鏈、聯(lián)盟鏈、企業(yè)鏈都屬于許可鏈。許可鏈引入身份驗(yàn)證機(jī)制，只有獲得授權(quán)的節(jié)點(diǎn)才能加入網(wǎng)絡(luò)，這使得許可鏈上的節(jié)點(diǎn)數(shù)大大減少，且不需要激勵(lì)機(jī)制，系統(tǒng)的運(yùn)行效率更高、交易成本更低。因此，許可鏈?zhǔn)钱?dāng)前商業(yè)應(yīng)用領(lǐng)域的主流。

在溯源體系中，農(nóng)產(chǎn)品產(chǎn)業(yè)鏈的參與者構(gòu)成一個(gè)利益共同體，但同時(shí)又不能完全信任，在現(xiàn)實(shí)中存在合作關(guān)系或交易關(guān)系，但不是隸屬關(guān)系，所以農(nóng)產(chǎn)品溯源系統(tǒng)選用許可鏈中的聯(lián)盟鏈。

盡管存在名稱使用差異、甚至混用概念的現(xiàn)象，但是應(yīng)該看到，相當(dāng)一些學(xué)者對(duì)美國學(xué)的起源、發(fā)展、理論與方法等方面的認(rèn)識(shí)趨于一致。美國學(xué)作為一個(gè)獨(dú)立學(xué)科，是隨著美國綜合國力的強(qiáng)盛，隨著美國文化的獨(dú)特性逐漸得到認(rèn)可才在美國學(xué)界興起并得以發(fā)展?？鐚W(xué)科、關(guān)注文化研究被認(rèn)為是美國學(xué)的基本特征。

Hyperledger Fabric是超級(jí)賬本(hyperledger)下的一個(gè)開源框架項(xiàng)目，其前身為IBM Open BlockChain項(xiàng)目。不同于比特幣和以太坊，F(xiàn)abric是專門面向企業(yè)的聯(lián)盟鏈開發(fā)平臺(tái)，特別提供了完備的身份認(rèn)證和權(quán)限管理、可插拔的共識(shí)協(xié)議、即插即用的模塊化組件和可配置架構(gòu)，智能合約的編寫支持主流計(jì)算機(jī)語言(Java、Go、Node.js)。這些差異化設(shè)計(jì)使得Fabric具有較強(qiáng)的業(yè)務(wù)需求適配性，被廣泛應(yīng)用于金融、醫(yī)療、政務(wù)(公證、征信、審計(jì)、投票)、物流供應(yīng)鏈(供應(yīng)鏈管理、產(chǎn)品溯源)等多個(gè)領(lǐng)域。

1.3 賬本數(shù)據(jù)和狀態(tài)數(shù)據(jù)

商業(yè)區(qū)塊鏈要求以區(qū)塊鏈平臺(tái)作為基礎(chǔ)，構(gòu)建1個(gè)企業(yè)級(jí)應(yīng)用系統(tǒng)，必然離不開數(shù)據(jù)存儲(chǔ)的支持。fabric網(wǎng)絡(luò)中的每個(gè)合法參與者都可以持有完整的數(shù)據(jù)副本，包括賬本數(shù)據(jù)(ledger)和狀態(tài)數(shù)據(jù)(state database)。賬本數(shù)據(jù)以鏈?zhǔn)浇Y(jié)構(gòu)保存一系列有序的、不可變的交易記錄，它基于二進(jìn)制文件的形式存儲(chǔ)，默認(rèn)的區(qū)塊文件大小上限為64 MB，一個(gè)賬本能保存的最大數(shù)據(jù)量約為61 TB。狀態(tài)數(shù)據(jù)用于記錄交易執(zhí)行的結(jié)果(類似于比特幣的賬戶余額)，它基于Key-Value分布式數(shù)據(jù)庫的形式存儲(chǔ)，支持插件化的數(shù)據(jù)訪問，可選用谷歌 LevelDB或Apache CouchDB。LevelDB支持主鍵查詢、復(fù)合主鍵查詢、主鍵范圍查詢、主鍵歷史查詢；CouchDB除了支持以上查詢外，還支持富查詢(非主鍵屬性查詢)及分頁。

1.4 節(jié)點(diǎn)

Fabric網(wǎng)絡(luò)由眾多節(jié)點(diǎn)構(gòu)成，按照功能不同，節(jié)點(diǎn)主要分為2類：對(duì)等節(jié)點(diǎn)(peer節(jié)點(diǎn))、排序節(jié)點(diǎn)(orderer節(jié)點(diǎn))。每個(gè)對(duì)等節(jié)點(diǎn)都擁有1份完整的數(shù)據(jù)副本和智能合約程序，它具有記賬功能(committer)和背書功能(endorser)。背書服務(wù)主要執(zhí)行智能合約；記賬服務(wù)主要持久化賬本數(shù)據(jù)和狀態(tài)數(shù)據(jù)。排序節(jié)點(diǎn)只包含賬本數(shù)據(jù)，不包含狀態(tài)數(shù)據(jù)，排序服務(wù)主要對(duì)形成共識(shí)的交易記錄進(jìn)行排序并生成區(qū)塊。共識(shí)行為由所有對(duì)等節(jié)點(diǎn)參與形成，智能合約觸發(fā)的交易執(zhí)行由對(duì)等節(jié)點(diǎn)和排序節(jié)點(diǎn)協(xié)作完成。

2 進(jìn)口農(nóng)產(chǎn)品溯源系統(tǒng)的架構(gòu)設(shè)計(jì)

進(jìn)口農(nóng)產(chǎn)品溯源系統(tǒng)采用5層架構(gòu)模型，自底向上依次是數(shù)據(jù)源、數(shù)據(jù)層、網(wǎng)絡(luò)層、服務(wù)層、應(yīng)用層(圖2)。

數(shù)據(jù)源來自進(jìn)口農(nóng)產(chǎn)品產(chǎn)業(yè)鏈上的生產(chǎn)商、加工商、海關(guān)、物流服務(wù)商、銷售商等在各自環(huán)節(jié)獲取到的與溯源相關(guān)的產(chǎn)品信息。數(shù)據(jù)層的功能是對(duì)數(shù)據(jù)源提供的產(chǎn)品信息進(jìn)行存儲(chǔ)。賬本區(qū)塊以Merkle樹為基礎(chǔ)保存交易記錄，區(qū)塊頭包含時(shí)間戳并采用Hash算法進(jìn)行加密；區(qū)塊體的內(nèi)容是以非對(duì)稱加密算法處理后的交易記錄。選擇CouchDB保存農(nóng)產(chǎn)品的狀態(tài)數(shù)據(jù)。網(wǎng)絡(luò)層是區(qū)塊鏈平臺(tái)信息傳輸?shù)幕A(chǔ)。在對(duì)等網(wǎng)絡(luò)環(huán)境中，每一個(gè)節(jié)點(diǎn)都具有相同的信息地位，網(wǎng)絡(luò)信息的傳播以點(diǎn)對(duì)點(diǎn)的方式進(jìn)行，這是區(qū)塊鏈非集中化特點(diǎn)的體現(xiàn)。共識(shí)機(jī)制是網(wǎng)絡(luò)中多個(gè)節(jié)點(diǎn)對(duì)一筆交易記錄是否提交到賬本以及提交的順序達(dá)成一致的過程，它可以解決分布式環(huán)境下如何保持?jǐn)?shù)據(jù)存儲(chǔ)一致性的問題。服務(wù)層是系統(tǒng)功能實(shí)現(xiàn)的核心。智能合約是能在區(qū)塊鏈平臺(tái)上執(zhí)行的業(yè)務(wù)代碼或數(shù)字化協(xié)議，它是應(yīng)用層與數(shù)據(jù)層交互的接口，提供數(shù)據(jù)上鏈、數(shù)據(jù)讀取等功能。同時(shí)，服務(wù)層也規(guī)定了節(jié)點(diǎn)接入、身份驗(yàn)證的規(guī)則，它根據(jù)PKI(公鑰基礎(chǔ)設(shè)施)規(guī)范由CA(證書授權(quán)中心)為授權(quán)節(jié)點(diǎn)頒發(fā)數(shù)字證書和密鑰文件，以確保節(jié)點(diǎn)之間的安全通信。應(yīng)用層通過Web瀏覽器頁面、移動(dòng)端APP、微信小程序、可用于二次開發(fā)的API等多種形式滿足用戶使用溯源系統(tǒng)的需求，包括監(jiān)管部門激活溯源碼初始化產(chǎn)品信息、產(chǎn)業(yè)鏈企業(yè)記錄各環(huán)節(jié)產(chǎn)品信息、消費(fèi)者查詢產(chǎn)品溯源信息等。

3 進(jìn)口農(nóng)產(chǎn)品溯源系統(tǒng)的功能實(shí)現(xiàn)

3.1 網(wǎng)絡(luò)部署

根據(jù)上述系統(tǒng)架構(gòu)模型的設(shè)計(jì)和農(nóng)產(chǎn)品產(chǎn)業(yè)鏈流程的分析，構(gòu)建基于聯(lián)盟區(qū)塊鏈的進(jìn)口農(nóng)產(chǎn)品溯源系統(tǒng)，系統(tǒng)依托Hyperledger Fabric實(shí)現(xiàn)，其網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)見圖3，涉及到的主要軟件及版本包括Hyperledger Fabric 1.4.11、Hyperledger Fabric CA 1.4.2、Ubuntu 16.04、Docker 18.06社區(qū)版、Docker Compose 1.22、Go 1.10、區(qū)塊鏈性能測試工具Hyperledger Caliper 0.4.2及Node.js 8.17。

系統(tǒng)總計(jì)部署9個(gè)網(wǎng)絡(luò)節(jié)點(diǎn)，其中5個(gè)對(duì)等節(jié)點(diǎn)、3個(gè)排序節(jié)點(diǎn)、1個(gè)CA服務(wù)器節(jié)點(diǎn)，對(duì)等節(jié)點(diǎn)和排序節(jié)點(diǎn)組成Fabric對(duì)等網(wǎng)絡(luò)。CA服務(wù)器負(fù)責(zé)完成針對(duì)網(wǎng)絡(luò)節(jié)點(diǎn)和用戶的注冊(cè)、鑒權(quán)、身份管理、證書頒發(fā)/更新/撤銷等安全許可工作；對(duì)等節(jié)點(diǎn)負(fù)責(zé)背書、記賬和數(shù)據(jù)存儲(chǔ)；排序節(jié)點(diǎn)借助于Apache Kafka組件實(shí)現(xiàn)交易排序，并在排序服務(wù)接口中加入基于BFT(拜占庭容錯(cuò))協(xié)議的算法。

3.2 存儲(chǔ)結(jié)構(gòu)的設(shè)計(jì)

在生產(chǎn)到銷售的流通過程中，農(nóng)產(chǎn)品會(huì)經(jīng)歷眾多環(huán)節(jié)，每個(gè)環(huán)節(jié)關(guān)注的產(chǎn)品信息是不同的，存儲(chǔ)結(jié)構(gòu)規(guī)定了各個(gè)環(huán)節(jié)需要提交到溯源系統(tǒng)中的產(chǎn)品信息的內(nèi)容，具體要求見表1。產(chǎn)業(yè)鏈各環(huán)節(jié)企業(yè)需要正確提交該環(huán)節(jié)的產(chǎn)品信息，其中主要產(chǎn)品信息是消費(fèi)者查詢溯源信息時(shí)的展現(xiàn)內(nèi)容，它多與時(shí)間、產(chǎn)品質(zhì)量、源端/末端企業(yè)有關(guān)；次要產(chǎn)品信息用于當(dāng)產(chǎn)品出現(xiàn)安全問題時(shí)追溯問題環(huán)節(jié)、定位責(zé)任主體使用，也關(guān)注中間商的業(yè)務(wù)情況。

表1 產(chǎn)品信息在溯源系統(tǒng)中的存儲(chǔ)結(jié)構(gòu)

3.3 溯源碼的設(shè)計(jì)

進(jìn)口農(nóng)產(chǎn)品的產(chǎn)業(yè)鏈冗長且復(fù)雜，對(duì)于同一個(gè)產(chǎn)品，雖然有眾多不同環(huán)節(jié)的產(chǎn)品信息，但仍然須要選用格式統(tǒng)一且唯一的溯源碼，才能便于產(chǎn)品數(shù)據(jù)的采集和管理。溯源碼是產(chǎn)品銷售時(shí)承載追溯信息、直接展現(xiàn)給消費(fèi)者的統(tǒng)一代碼。當(dāng)前，條形碼標(biāo)簽仍然是使用最廣泛的普通農(nóng)產(chǎn)品標(biāo)志方式。

EAN·UCC全球統(tǒng)一標(biāo)識(shí)系統(tǒng)是全球范圍內(nèi)通用的商業(yè)語言，可有效用于對(duì)農(nóng)產(chǎn)品的標(biāo)志。它通過對(duì)農(nóng)產(chǎn)品從生產(chǎn)到加工、從倉儲(chǔ)到銷售各環(huán)節(jié)對(duì)象的標(biāo)志，使產(chǎn)業(yè)鏈有效銜接。一旦出現(xiàn)安全問題，可以通過條碼標(biāo)志進(jìn)行追溯，查出問題出現(xiàn)的環(huán)節(jié)，基至可以追溯到產(chǎn)品生產(chǎn)的源頭。所以，溯源碼采用EAN·UCC-128條碼作為數(shù)據(jù)載體，條碼設(shè)計(jì)方案為GTIN(全球貿(mào)易項(xiàng)目代碼)+產(chǎn)品日期+產(chǎn)品產(chǎn)地，共32位(圖4)。溯源碼具體的編碼結(jié)構(gòu)見表2。

表2 溯源碼編碼結(jié)構(gòu)

出于規(guī)范使用的目的，溯源碼應(yīng)由監(jiān)管機(jī)構(gòu)統(tǒng)一規(guī)劃和管理。農(nóng)產(chǎn)品產(chǎn)業(yè)鏈源頭企業(yè)向監(jiān)管機(jī)構(gòu)申請(qǐng)溯源碼；監(jiān)管機(jī)構(gòu)審核申請(qǐng)后在溯源系統(tǒng)中激活溯源碼、初始化產(chǎn)品信息，并在線下分配溯源碼；產(chǎn)業(yè)鏈各環(huán)節(jié)企業(yè)根據(jù)溯源碼更新溯源系統(tǒng)中的產(chǎn)品信息；消費(fèi)者購買商品后根據(jù)溯源碼在溯源系統(tǒng)中查詢產(chǎn)品的溯源信息?？梢?，溯源碼貫穿于追溯管理的全流程。

3.4 智能合約的實(shí)現(xiàn)

智能合約在Fabric中也被稱為鏈碼(chaincode)，它是實(shí)現(xiàn)用戶定制功能的可編程協(xié)議。在區(qū)塊鏈金融應(yīng)用中，智能合約定義了交易規(guī)則，可按照規(guī)則自動(dòng)運(yùn)行而不受人為干預(yù)，相當(dāng)于使用程序和算法來代替仲裁和合同的執(zhí)行，實(shí)現(xiàn)“代碼即法律”的目標(biāo)。農(nóng)產(chǎn)品溯源系統(tǒng)通過調(diào)用智能合約來操作賬本數(shù)據(jù)和狀態(tài)數(shù)據(jù)，主要包括查詢操作和更新操作(增加、更改)。在Fabric中使用Go語言編寫智能合約，F(xiàn)abric提供的Init()方法用于系統(tǒng)初始化，Invoke()方法用于交易執(zhí)行或數(shù)據(jù)訪問。在Invoke()方法下定義3個(gè)參數(shù)：功能類型functionType、溯源碼tracingCode、產(chǎn)品信息productInfo，functionType對(duì)應(yīng)3種接口完成功能不同的業(yè)務(wù)需求(表3)。

表3 進(jìn)口農(nóng)產(chǎn)品溯源系統(tǒng)中的智能合約設(shè)計(jì)

智能合約程序會(huì)部署在每一個(gè)對(duì)等節(jié)點(diǎn)上，對(duì)等節(jié)點(diǎn)保存有完整的數(shù)據(jù)副本，所以查詢操作在本地即可完成，無需牽涉到其他節(jié)點(diǎn)。由于共識(shí)機(jī)制，更新操作需要網(wǎng)絡(luò)中的其他對(duì)等節(jié)點(diǎn)和排序節(jié)點(diǎn)參與工作(圖5)。由圖5可知，對(duì)于更新數(shù)據(jù)的共識(shí)達(dá)成是在模擬執(zhí)行過程中完成的，任一對(duì)等節(jié)點(diǎn)模擬執(zhí)行失敗都會(huì)導(dǎo)致本次更新數(shù)據(jù)無法提交，系統(tǒng)使用預(yù)處理的方式保證各個(gè)對(duì)等節(jié)點(diǎn)數(shù)據(jù)的一致性。

4 應(yīng)用與試驗(yàn)分析

為了提高進(jìn)口農(nóng)產(chǎn)品溯源系統(tǒng)的實(shí)用性，還應(yīng)向使用者提供界面友好、操作便捷的可視化交互方式，包括基于瀏覽器的Web應(yīng)用、移動(dòng)端APP、微信小程序等。圖6為Android端APP進(jìn)行溯源信息查詢的結(jié)果界面，消費(fèi)者輸入溯源碼，即可瀏覽該產(chǎn)品的生產(chǎn)、通關(guān)、倉儲(chǔ)、物流、銷售各環(huán)節(jié)信息。

Fabric平臺(tái)的出塊參數(shù)在一定程度上會(huì)影響系統(tǒng)的整體性能。設(shè)置出塊超時(shí)時(shí)間(BatchTimeout)為20 s、區(qū)塊最大交易數(shù)量(MaxMessageCount)為 5 000 筆、區(qū)塊首選規(guī)模(PreferredMaxBytes)為 2.5 MB、區(qū)塊最大規(guī)模(AbsoluteMaxBytes)為 100 MB，設(shè)置出塊條件為“新交易觸發(fā)”。在上述參數(shù)條件下，系統(tǒng)滿負(fù)荷運(yùn)行1年，每個(gè)對(duì)等節(jié)點(diǎn)最多產(chǎn)生數(shù)據(jù)為3.76 TB，該數(shù)據(jù)規(guī)模完全可以被商業(yè)應(yīng)用接受。

采用區(qū)塊鏈性能測試工具Hyperledger Caliper對(duì)進(jìn)口農(nóng)產(chǎn)品溯源系統(tǒng)進(jìn)行負(fù)載測試，從吞吐量和延遲時(shí)間2個(gè)維度評(píng)估系統(tǒng)的可用性和工作效率。Caliper模擬大量用戶，以并發(fā)提交業(yè)務(wù)的方式，自動(dòng)化重復(fù)執(zhí)行測試用例，獲取不同負(fù)載情況下的性能指標(biāo)測量值，確定系統(tǒng)所能提供的最大服務(wù)級(jí)別。

設(shè)計(jì)更新操作(label：transfer)和查詢操作(label：query)2類測試：更新操作進(jìn)行5輪，總計(jì)提交2 000筆/輪，每輪并發(fā)提交分別為50、100、150、200、250筆/s；查詢操作進(jìn)行2輪，總計(jì)提交 5 000筆/輪，每輪并發(fā)提交分別為200、400筆/s。測試結(jié)果(系統(tǒng)吞吐量、平均延遲時(shí)間)如表4所示。對(duì)于更新操作，系統(tǒng)吞吐量隨著并發(fā)提交量逐步增長，當(dāng)并發(fā)提交量為150筆/s時(shí)，系統(tǒng)吞吐量達(dá)到峰值112筆/s，此時(shí)平均延遲時(shí)間為4.06 s(圖7)。對(duì)于查詢操作，并發(fā)提交量為200筆/s時(shí)性能最佳，系統(tǒng)吞吐量為196筆/s、平均延遲時(shí)間為 1.47 s。由于查詢操作只需要1個(gè)對(duì)等節(jié)點(diǎn)負(fù)擔(dān)，而更新操作的過程波及全網(wǎng)絡(luò)，所以查詢操作的性能要好于更新操作。在實(shí)際應(yīng)用中，查詢溯源信息要遠(yuǎn)遠(yuǎn)多于更新產(chǎn)品信息，這與溯源系統(tǒng)業(yè)務(wù)基于區(qū)塊鏈技術(shù)來設(shè)計(jì)是相符合的。

表4 性能測試結(jié)果數(shù)據(jù)

總體來看，進(jìn)口農(nóng)產(chǎn)品溯源系統(tǒng)的吞吐量為110～200筆/s，平均延遲時(shí)間為1.5～4.0 s，在可用性上，具有較好的用戶體驗(yàn)，在工作效率上，具備承載企業(yè)級(jí)應(yīng)用的能力。

5 結(jié)語

近期，傳染性更強(qiáng)的新冠病毒變異株(Delta、Delta+、Lambda)導(dǎo)致境外多個(gè)國家和地區(qū)的疫情反彈。國內(nèi)的疫情防控工作從“人防”轉(zhuǎn)變?yōu)椤叭宋锿馈保瑢?duì)進(jìn)口農(nóng)產(chǎn)品的有效追溯成為保障人民群眾健康安全的重要手段。本研究以Hyperledger Fabric為基礎(chǔ)平臺(tái)，構(gòu)建基于聯(lián)盟區(qū)塊鏈的進(jìn)口農(nóng)產(chǎn)品溯源系統(tǒng)，系統(tǒng)利用區(qū)塊鏈非集中化、不可篡改、可追溯等技術(shù)特性，不僅可以實(shí)現(xiàn)進(jìn)口農(nóng)產(chǎn)品從境外產(chǎn)地到境內(nèi)消費(fèi)者的全流程跟蹤管理，還解決了產(chǎn)業(yè)鏈上下游之間的“信任問題”。

區(qū)塊鏈?zhǔn)桥c生俱來的信任機(jī)器，是在完全不信任的環(huán)境下建立信任機(jī)制的技術(shù)，本研究將區(qū)塊鏈技術(shù)成功應(yīng)用于進(jìn)口農(nóng)產(chǎn)品溯源系統(tǒng)，并證明了不借助第三方平臺(tái)建立數(shù)據(jù)共享體系的可行性，以期為區(qū)塊鏈技術(shù)在其他領(lǐng)域的應(yīng)用提供新的思路和方法。