面向獼猴桃質量溯源的聯盟鏈跨組織鏈上合同交易機制

景 旭 秦源澤

(西北農林科技大學信息工程學院， 陜西楊凌 712100)

0 引言

基于區塊鏈技術實現農產品溯源，可以有效提升信息的完整性、可追溯性及可信性，能實現多個主體協作信任，有利于供應鏈管理的技術創新與模式升級[1-2]，對于提升農產品的質量保障，進而從食源上保證人民生命健康具有重要意義。

基于區塊鏈技術的特點，國內外學者在農產品溯源方面開展了廣泛的研究。YANG等[3]針對農產品追溯系統提出了基于q-ROF集(q-Rung orthopair fuzzy)的設計模型選擇決策算法。GEORGE等[4]提出了基于區塊鏈和產品標識符的餐廳溯源模型，從供應鏈的不同利益相關者獲取數據并分離，應用食品質量指數(Food quality index，FQI)算法生成FQI值。許繼平等[5]提出了適用于糧油食品供應鏈的雙模型存儲機制和管理供應鏈信息的智能合約，實現了糧油食品供應鏈信息的采集、查詢、監控和追溯。葛艷等[6]提出了基于區塊鏈的危害分析及關鍵控制點(Hazard analysis and critical control points，HACCP)的質量溯源模型，設計智能合約實現溯源數據的上下鏈和質量自動判斷。任守綱等[7]基于信譽監督機制改進了拜占庭容錯算法，構建了基于聯盟鏈的農作物全產業鏈信息溯源平臺。可以看出，在現有基于區塊鏈的農產質量溯源研究中，基本上均假設整個產業鏈的生產活動在一個組織內完成，并通過一個固定溯源碼將各環節的生產信息依次記錄在區塊鏈中，按照既定溯源碼反向追溯實現溯源。它僅適用于單組織管理的產業鏈溯源，沒有考慮產業鏈分為多個組織后跨組織溯源的問題，導致不同組織在賬本中的數據缺乏邏輯上的連續性與完整性。

在實際農業生產環境中，農資供應、田間生產、場內加工與儲藏、電商銷售等生產環節在時間和空間上跨度均比較大[8]，所以每個生產環節基本由相互獨立的組織承擔，在同一個組織內部的不同環節也基本由相互獨立的部門承擔。不同組織的生產溯源信息通過組織間的合同交易關聯，合同交易一般依賴第三方中心機構管理。合同交易時，采購商向供應商發起采購意向書，供應商擬定合同，與采購商簽署交易合同。雙方均對合同簽名，合同生效，交易完成。

針對上述問題，結合生產實踐中合同交易的過程，提出一種面向獼猴桃質量溯源的聯盟鏈跨組織鏈上合同交易機制。將現實供應鏈中交易雙方對合同條款簽字確認的過程，轉移到聯盟鏈上。通過兩次鏈上的關聯確認，實現跨組織的不可否認交易。保證交易雙方權益，無需依賴第三方中心機構管理，更好地發揮供應鏈的不同組織在溯源體系中的作用。本文選擇聯盟鏈搭建獼猴桃全產業鏈溯源系統的區塊鏈網絡，借助智能合約技術將獼猴桃生產的過程信息價值化；采用散列值上鏈減輕鏈上壓力；通過組織間交易合同的合同編號關聯產業鏈的溯源數據、責任人和責任企業，組織與組織間的交易合同可使獼猴桃在全產業鏈的溯源數據在鏈上具有邏輯連續性，當單節點偽造數據時，其他環節信息無法追溯，可快速定位到問題組織。

1 基于聯盟鏈的獼猴桃全產業鏈溯源體系結構

按照開放程度，區塊鏈可以劃分為公有鏈[9]、私有鏈[10]和聯盟鏈[11]。公有鏈的訪問門檻低、節點數目過多、共識時間較長、交易速度慢，不符合交易頻繁的區塊鏈溯源系統對性能和效率的要求。私有鏈由中心機構管理，交易不需要所有節點確認，違背了去中心化的初衷[12]，鏈上數據存在被私自修改的可能，不能從根本上解決作弊問題。聯盟鏈是由多個機構共同管理的組織體系，聯盟鏈的Fabric ca身份認證服務依賴于PKI體系[13]和密碼技術[14]以保證網絡具有安全可靠的準入制；聯盟鏈有靈活的智能合約[15]定制機制，可以滿足供應鏈不同組織復雜多變的業務需求；聯盟鏈可以支持多種共識機制[16]，交易效率較高，可以滿足用戶無感知的溯源需求[17]。在獼猴桃全產業鏈溯源中，產業鏈的上下游主體在現實中既存在競爭關系，也有一定信任關系，構成天然的聯盟組織鏈條[18-19]，因此本研究選用聯盟鏈搭建獼猴桃全產業鏈溯源系統的區塊鏈網絡。通過分析獼猴桃從農業合作社采購生產資料、田間生產到銷售、運輸至消費者手中的整個產業鏈，本研究將獼猴桃全產業鏈分為農資采購、種植采摘、生產加工、質檢、銷售物流等5個生產環節。每個生產環節由相互獨立又相互依賴的組織承擔，構成聯盟鏈中的組織單位，包括農資電商、農業合作社、加工廠、質檢部門、電商平臺。聯盟各個組織在實際生產中是相互獨立的實體，除了農資電商、電商平臺無生產環節外，其余生產組織均有產、購、儲、加、銷等環節，而各個組織聯合在一起構成了獼猴桃完整的產業鏈。

每個組織詳細記錄獼猴桃當前生產過程的數據，包括生產基本信息、物聯網設備實時監測數據、生產活動記錄等。通過跨組織鏈上合同交易機制，完成以上5個組織生產活動溯源數據的鏈接，構成全產業鏈的數據鏈條閉環。以消費者的訂單號作為溯源碼，消費者通過溯源碼在賬本中查詢該批次獼猴桃在聯盟鏈內不同生產階段的交易合同編號，完成獼猴桃在各個生產組織有關產地、獼猴桃品質等溯源信息查詢。消費者僅能溯源獼猴桃質量相關的數據，監管部門溯源到每個生產環節的責任企業和責任人。基于聯盟鏈的獼猴桃全產業鏈溯源體系結構如圖1所示。

圖1 基于聯盟鏈的獼猴桃全產業鏈溯源體系結構Fig.1 Traceability architecture of kiwi fruit industry chain based on consortium blockchain

在圖1中，各組織通過分工合作形成產業鏈。農資電商平臺負責獼猴桃生產資料的采購、儲藏和銷售。農業合作社負責農資采購和獼猴桃的種植、施肥、噴藥、采摘和銷售等過程。加工廠負責獼猴桃的采購、分揀、脫毛、糖檢等，并按照品質為獼猴桃商品裝箱、冷庫儲藏和銷售。質檢部門負責獼猴桃的質量檢測。電商平臺負責獼猴桃商品采購、銷售和物流。組織平臺的Web服務器通過建立資源客戶端與區塊鏈網絡節點連接，使用代表合法身份的數字證書[20]與公鑰私鑰[21]證明身份，調用已安裝的智能合約在聯盟中進行交易。

在圖1中，通過組織間的協同與鏈上合同交易實現產業鏈的監督。通過對比跨組織的采購合同與銷售合同數量，監管部門可實現跨組織全產業鏈的監管；通過農資采購量、生產環境數據可預估合作社的產量，比對合作社銷售量與預估值，判斷合作社是否使用劣質農資；通過比對加工廠采購量與銷售量，判斷加工廠是否采購劣質獼猴桃；通過電商平臺采購量與銷售量比對，判斷是否存在電商平臺采購劣質獼猴桃。監管部門通過比對各個組織在賬本中的采購合同與銷售信息可監管每個環節交易量，實現獼猴桃全產業鏈的質量監測，以及發生質量問題時可追責至具體企業與責任人。

2 聯盟鏈內跨組織鏈上合同交易機制

在聯盟鏈的合同交易過程中，交易合同由聯盟鏈內所有組織成員節點共同管理。不同階段的合同交易業務對應不同鏈碼，客戶端通過SDK提供的API構建交易提案請求，并使用代表客戶端合法身份的證書對交易簽名(sign)，sign過程對應實際供應鏈交易方簽署合同的過程。客戶端發起交易提案后，將事務提交給背書節點進行背書簽名；收集到足夠數量的簽名后，將交易發送給排序節點打包成區塊；區塊被發送到主節點，主節點傳播給記賬節點，完成記賬后交易結束。利用靈活的智能合約體系和聯盟鏈的不可篡改[22]、時間戳[23-24]等特性，可以有效地將繁雜耗時的合同簽署過程用交易雙方兩次鏈上合同交易生成交易的方式保存在區塊鏈賬本中。

以加工廠與電商組織的交易流程為例，聯盟鏈內跨組織鏈上合同交易流程如圖2所示。

圖2 聯盟鏈內跨組織鏈上合同交易流程Fig.2 Cross-organization contract transaction process within consortium blockchain

詳細步驟包括：

(1)電商采購方按照采購計劃在加工廠銷售平臺填寫采購單，包括品名、數量、價格、交易平臺信息、采購人信息等，系統生成一個采購單號(SaleOrderNum)。為將責任實體信息與采購信息關聯，以保證責任實體信息完整性和減輕鏈上壓力，采用sha256安全散列算法[25]生成實體信息的散列值，將實體信息標識、實體信息的散列值和采購信息共同上鏈。采購訂單的具體數據項見表1。

(2)加工廠客戶端通過創建資源客戶端以連接peer0.factory.itcast.cn節點(FactoryNode)，電商平臺客戶端以相同方式連接peer0.dj.itcast.cn節點(DsNode)。在合同交易前，兩個節點需要安裝相同的鏈碼，負責兩組織合同交易及相關業務。加工廠銷售平臺自動判斷庫存是否滿足電商采購單的需求；確認信息無誤后，將訂單信息作為交易合同的內容，通過FactoryNode調用智能合約將銷售合同信息上鏈，實現向聯盟鏈發起銷售合同交易；將加工廠本地數據庫中銷售單狀態變更為3，等待電商組織向區塊鏈發起采購合同交易。

表1 采購訂單數據項Tab.1 Purchase order data items

(3)電商采購方通過DsNode在當前通道賬本中查詢加工廠銷售交易合同信息，調用智能合約發起采購確認，達成合同交易；對應state的key值是S+SaleOrderNum，value是訂單信息散列值與采購方信息散列值；當采購意向合同交易完成后，將電商本地數據庫的采購單狀態變更為1，采購入庫完成。

(4)加工廠銷售方以S+SaleOrderNum為state的key值，通過FactoryNode在當前通道賬本中查詢采購交易合同信息；確認無誤后，對加工廠數據庫的銷售單的狀態變更為1，銷售出庫完成。采購方、銷售方的鏈上交易完成，并且雙方組織的本地數據庫入庫、出庫均完成，跨組織鏈上合同交易完成。

采購合同單編號生成算法OrderPost表示采購員提交訂單(輸入數據+責任實體信息散列)獲取采購合同編號，其中，QueryByMonkeyPickAndCount表示按訂單品名和數量查找前一生產階段的銷售交易合同編號；QueryBySaleId表示按照電商平臺工商號查詢平臺信息；QueryByFacotryId表示按照加工廠工商號查詢加工廠信息；QueryByCustomer表示按照采購員工號查詢采購員信息；Hash表示使用sha256算法對參數生成定長的散列值；Left(20,str)表示對字符串取前20位操作；CurNum表示合同編號。采購合同單編號生成如算法1所示。

算法1：OrderPost(FactoryId;SaleId;OrderCustomerId;MonkeyPick;Count;OrderDate;Price)；

輸入：{FactoryId; SaleId; OrderCustomerId ; MonkeyPick; Count; OrderDate; Price}；

輸出：{CurNum}；

CoopSaleInfoNum= QueryByMonkeyPickAndCount(MonkeyPick, Count)

SaleHash = Hash(QueryBySaleId(SaleId))

FactoryHash= Hash(QueryByFacotryId(FacotyId))

OrderCustomerHash = Hash(QueryByCustomerId (CustomerId))

CurNum = Left(20, Hash(PreOrgNum，OrderCustomerId，OrderCustomerHash, Price))

return CurNum

加工廠發起銷售合同交易算法，Trade表示加工廠客戶端將銷售交易合同(業務處理過的數據args[])上鏈。其中，stub.GetState()_length表示判斷當前通道賬本中是否存在state的key值為“F+args[0]”的交易合同；TradeContent表示交易合同結構體，all_fileds表示交易合同結構體的具體數據項，對應表1字段2～12；Marsh表示將交易合同結構體的格式轉換成可上鏈的json格式。加工廠發起銷售合同交易如算法2所示。

算法2：(this*TracePlantCC)Trade(stub shim.ChaincodeStubInterface, args[]string)peer.Response；

輸入：{args[]}；

輸出：{更新區塊鏈賬本new_chain }；

if stub.GetState("F"+args[0])_length != 0;

return Exit

else:

var tradeInfo TradeContent:

var i =1;

for field in all_fileds:

tradeInfo.filed <- args[i++]

new_chain = stub.PutState("F"+args[0], Marsh(tradeInfo));

return

在聯盟內跨組織鏈上合同交易流程中，各組織可采用當前組織的采購交易合同編號作為溯源碼。每個組織的交易合同編號與前一個生產組織交易合同編號在鏈上直接關聯，隨著生產流程和組織交易動態生成。消費者最終的訂單編號生成規則同組織交易合同編號規則類似，消費者訂單編號與電商采購獼猴桃的交易合同編號直接關聯。這種類似merkle樹[26]結構的交易合同編號編碼方式，使得聯盟鏈的每個組織的交易合同在賬本中構成一條完整的合同鏈條。

3 獼猴桃質量溯源應用

本文以陜西齊峰果業有限公司的獼猴桃全產業鏈為研究模型，包含產前、產中和產后多階段，是關聯農資采購、種植采摘、生產加工、第三方質檢、物流銷售等多環節的完整鏈狀結構。本文研究跨組織鏈上合同交易業務場景下的溯源平臺要求參與方之間信息共享、風險共擔，最終實現“多贏”。溯源信息來源于物聯網設備數據、第三方檢測數據、生產活動信息等。每個組織的溯源信息及責任實體散列值通過智能合約記錄到聯盟鏈通道賬本中，并以當前組織采購交易合同編號作為溯源碼對組織內獼猴桃生產溯源信息進行記錄和追溯。

圖3 聯盟內溯源信息邏輯結構Fig.3 Logical structure of traceability information within consortium blockchain

根據聯盟鏈跨組織鏈上合同交易機制，結合獼猴桃全產業鏈溯源業務的實際需求，針對各個組織設計了一種單個生產環節溯源數據的存儲方案。某一環節的鏈上溯源數據包括溯源信息散列值，責任人身份證號、責任組織工商號與其信息散列值。具體鏈下溯源數據和責任實體明文信息存儲在各自組織的數據庫中。實現“鏈上鏈下雙存儲”的數據存儲方案，提供了對同一批次的獼猴桃與生產活動、責任人、責任企業等信息進行關聯的數據化方案。追溯數據采用Key-Value的方式進行存儲，將生產環節責任人身份證號(IdNumber)、責任人信息散列值(staffHash)、本地數據庫溯源信息記錄標識(InfoId)和溯源信息散列值(InfoHash)封裝，作為Value寫入賬本，Key則采用當前生產階段字母+當前組織訂單編號的組合，作為賬本Value中InfoId的索引和唯一標識。

在溯源系統內，不同組織平臺通過聯盟鏈內跨組織鏈上合同交易機制，保證各個組織的溯源信息在區塊鏈內邏輯具有完整性與一致性。鏈上的采購、銷售合同交易經過聯盟組織的成員節點共識后以交易的方式記錄在賬本中，交易信息公開透明。通過消費者溯源碼與各個組織的交易合同編號對一個批次的獼猴桃進行標識，實際生產活動中，各個組織以生產環節首字母和組織的交易合同編號作為state的key值，按照追溯數據鏈上存儲結構，對當前組織內所有生產環節的溯源數據依次上鏈。電商平臺與加工廠、加工廠與合作社、合作社與農資平臺之間的交易合同編號在聯盟內形成一條完整的鏈，各個交易合同編號又對各個組織溯源信息進行關聯，進而將整個聯盟內同一批次獼猴桃的溯源信息在賬本中關聯成一條完整的鏈。聯盟內溯源信息邏輯結構如圖3所示。

以加工廠工序為例介紹溯源數據上鏈流程。加工廠從合作社采購一批獼猴桃，需要經過臨時儲藏、脫毛、糖分檢測、質量測量、第三方抽樣、裝箱包裝和冷藏等環節，加工廠組織使用采購合同編號與生產環節首字母作為key值，依次對各個生產環節溯源數據散列值同該環節負責人、責任企業的散列值等信息執行上鏈操作。

獼猴桃溯源流程包括：消費者和監管部門通過溯源碼進行溯源，通過最終生成的溯源碼在鏈上獲取各個組織的溯源碼，分別調用相應的智能合約查詢各組織的溯源數據，包括從賬本獲取某一組織的某一個生產環節的溯源數據標識、責任人身份證號、企業工商號與各自散列值。通過溯源信息標識查詢組織本地數據庫，獲取溯源數據與實體的明文信息，計算得出對應明文的sha256散列值，以鏈上的散列為標準，對鏈下的溯源數據生成散列值進行校驗。根據校驗結果，判斷鏈下數據是否被篡改，如果發生篡改，消費者端顯示溯源異常，監管部門可進一步追責具體責任人和責任企業。

4 測試

4.1 測試環境

本文研究了一種面向獼猴桃質量溯源的聯盟鏈跨組織鏈上合同交易機制，基于這種聯盟鏈內跨組織鏈上合同交易機制設計并實現了獼猴桃質量溯源系統。選擇Hyperledger Farbic 1.4搭建區塊鏈網絡，操作系統是64位的Ubuntu16.04LTS，內存4 GB，磁盤空間40 GB。測試環境如下：

(1)基本環境：安裝Hyperledger Fabric的依賴容器服務docker19.03.6，使用命令行sudo apt install docker.io，完成后安裝應用程序docker-compose，使用命令行sudo apt install docker-compose，使用腳本下載fabric鏡像。

(2)溯源系統區塊鏈網絡：在crypto-config.yaml中配置聯盟組織與節點信息，在configtx.yaml中配置創世區塊和通道(Channel)信息；采用solo共識算法，將每個區塊最大打包時間間隔為2 s、區塊的最大交易數為10筆、區塊最大字節數為32 MB；在docker-compose.yaml中配置網絡的容器信息，使用cryptogen工具和ca服務器為聯盟網絡生成組織結構和身份文件；使用configtxgen生成創始區塊和生成通道文件、錨節點更新文件等；每個組織配置了鍵值對數據庫leveldb備份區塊鏈數據，運行docker-compose up-d啟動區塊鏈網絡。測試區塊鏈網絡的節點信息如表2所示。

(3)服務器與區塊鏈網絡交互環境：組織的Web服務器通過Fabric-SDK-Go與區塊鏈網絡交互，智能合約實現組織業務邏輯；使用beego框架搭建服務器，前端使用bootstrap4.0搭建自適應頁面框架；通過data組件、JQuery和Ajax等進行前后端數據交互，組織通過權限控制管理存儲各組織本地明文信息mysql數據庫；終端用戶使用手機App或瀏覽器連接組織節點。

(4)區塊鏈賬本查看工具：選擇peer0.jg.itcast.cn節點(可以選擇通道內任意peer節點)配置區塊鏈瀏覽器(Hyperledger Explorer)，用于隨時查看當前通道內賬本的交易和區塊信息，包括區塊高度、區塊哈希、交易發起組織、鏈碼信息、背書節點等。

4.2 測試與分析

(1)跨組織鏈上交易

采購人員登陸銷售組織平臺下單，銷售管理人員驗證訂單合法后向區塊鏈發起交易，采購人員在賬本中查詢銷售方的銷售意向，最后向區塊鏈發起采購確認，如圖4a所示。雙方鏈上合同交易完成，跨組織交易結束。賬本中對應的合同交易信息如圖4b所示。

圖4 跨組織交易確認Fig.4 Inter-organizational transaction confirmation

(2)消費者溯源

以消費者對單號2976e176b0f9726ae4ac溯源為例，在賬本中僅需查找得到加工廠溯源碼452935032f6296b9086a和合作社溯源碼Ob25f0fc68959230a96f。按照各組織溯源碼查詢鏈上溯源信息id與散列值；根據id查詢組織本地數據庫，將得到的明文信息拼成字符串；比對校驗拼接字符串的sha256散列值與鏈上對應id的散列值；校驗成功后顯示獼猴桃的產地、生產廠家、銷售物流和獼猴桃糖分、農藥殘留等質量相關的明文信息，如圖5所示。

圖5 溯源功能結果Fig.5 Traceability function results

(3)當前上鏈交易信息

測試以加工廠節點通過調用智能合約，上鏈批次c6a5591f41a93e92c253的分揀生產數據為例。

通過Hyperledger Explorer顯示該交易所在的區塊信息，如圖6a所示，其中區塊號(區塊高度)為2528，區塊哈希為32bec7de71de4b4f29a46f2aa701cb c7ea057a8170e84afb7f38df ba65450a88，前一區塊哈希為6ef2f0cd71654ac99ee9ee72952ce81bba625b6db 5c996c03bd33 c9946693209。上鏈交易具體信息如圖 6b所示，其中Txid為dac8e34bbf52873c0bc44e 0239 ff3a8e67989feOe0b616c90550784e5bf07341，調用鏈碼為FactoryCC，寫入賬本state的key為"Ac6a5591f41a93e92c253"(環節字母+交易合同編號)、value為"ldNumber:545875188508145 26X,staffHash:c00664771475d987abl24cea6d292eab23eb 87bf46838012116b33151bc3da64,Infold:c6a5591f41 a93e92c253,InfoldHash:b092e4b7b66ac96175ea28dd 4776ba06640d7a5a38561a14894075897d5f9633"(操作人員身份證號、信息散列值、溯源數據號、溯源信息散列值)等信息。

圖6 交易信息上鏈Fig.6 Uploading transactional information to blockchain

(4)用戶數據上鏈時間

分別測試1×104、3×104、5×104、7×104、9×104、1.1×105條記錄的上鏈時間，取相同記錄運行10次的時間作為上鏈時間，測試結果如圖7所示。

圖7 上鏈交易時間Fig.7 Time of uploading transactional data to blockchain

由圖7可以看出，用戶在不同上鏈數據條數下，執行一次上鏈操作平均用時約102 ms，不受賬本中記錄總量影響。這是由于如果網絡中上鏈交易量不能達到生成區塊的交易條數時，上鏈一條數據與配置文件設置的最大出塊時間2 s一致，上鏈交易時間由設置的出塊條件和共識算法決定。

(5)鏈上溯源效率

與其他非合同交易機制的區塊鏈溯源系統(簡稱非合同機制)相比，本文溯源模型采用合同交易機制(簡稱合同機制)增加了訂單查詢和校驗過程。通過測試state的key鍵遍歷查詢方法，在賬本數據總量分別為1×104、3×104、5×104、7×104、9×104、1.1×105條記錄的條件下，設置1、200、400、600、800、1 000、1 200批次6組溯源實驗在非合同機制與合同機制的查詢時間。為了避免偶然性誤差每個數據項都取10次實驗的平均值作為結果。

非合同機制與合同機制的溯源查詢時間效率η計算公式為

(1)

式中tA——聯盟鏈兩組織交易合同模式下消費者進行批次溯源的時間

tB——不使用訂單交易只通過唯一標識在各組織內部進行批次溯源的時間

N=|η(A,B)|，r表示相關系數，其計算公式為

(2)

式中 Cov(X,Y)——X、Y的協方差

D(X)、D(Y)——X、Y的方差

當賬本數據量相差兩萬條數據時，查詢時間變化很小，對比賬本中存在104條記錄和1.1×105條記錄查詢時間如圖8所示，6組溯源實驗在不同存儲條數下的N如表3所示。

圖8 查詢效率對比Fig.8 Comparison of query efficiency

表3 不同存儲條件下不同批次的溯源效率Tab.3 N of different batches under different storage conditions%

由圖8可以看出，在1×104和1.1×105的存儲條數下，批次查詢1 000條完整溯源數據，查詢時間由5.843×104ms變為6.554×104ms，平均每條完整溯源時間延長7.11 ms。

由表3可以得出，在存儲1×104、3×104、5×104、7×104、9×104、1.1×105條記錄的條件下，r=0.097 6，表明查詢時間效率變化率與區塊鏈網絡中的存儲條數變化關系不大。在批次查詢1、200、400、600、800、1 000、1 200條記錄條件下，r=-0.819，N與批次查詢條數呈負線性相關，且查詢條數超過1 200條后，N趨近0。跨組織鏈上合同交易機制在實際溯源系統的應用中，隨著溯源批次量增加，對效率的影響變小。

本文所設計聯盟內跨組織鏈上交易合同機制，相對于大多數區塊鏈溯源系統，溯源效率影響很小，在用戶可接受范圍內。

5 結論

(1)以獼猴桃全產業鏈生產為研究對象，提出了聯盟鏈跨組織鏈上合同交易機制。該機制通過交易雙方在鏈上發起采購合同交易和銷售合同交易，將現實中雙方簽字確認合同的過程以交易的形式保存在區塊鏈賬本中。聯盟鏈的各個組織使用當前組織交易合同編號作為溯源碼，使得每個組織的溯源碼與前一生產組織的溯源碼在鏈上直接關聯，產業鏈各個組織的溯源數據通過鏈上環環相扣的溯源碼實現邏輯串聯。生產環節數據上鏈時將溯源數據散列值與現實中代表責任實體的標識同散列值一同上鏈，不僅減輕了鏈上數據壓力，同時解決了數據庫主鍵易篡改、追責效率低等問題。通過跨組織數據協調校準，實現監管部門監管全產業鏈。本研究有效解決了實際生產中同一個批次獼猴桃溯源信息在多組織的聯盟鏈賬本的邏輯的連續性與完整性問題，有利于提升獼猴桃質量溯源可信度，保障獼猴桃生產質量。

(2)基于Hyperledger Fabric搭建了一個獼猴桃全產業鏈溯源平臺，實現了跨組織的鏈上合同交易、消費者質量溯源和監管追責；當區塊鏈網絡中上鏈交易量較大時，用戶上鏈一條數據的平均時間約為102 ms；當區塊鏈網絡中上鏈交易量較小時，上鏈數據與最大出塊的平均時間約為2 s；通過對比合同機制與非合同機制溯源的查詢效率，可以看出本系統平均每條完整溯源平均時間延長約7.11 ms，在用戶可接受范圍內。