基于雙區塊鏈的產品溯源系統研究與實現

韓妍妍, 魏萬奇, 竇凱麗, 張 齊

(1.北京電子科技學院 電子與通信工程系,北京 100070;2.西安電子科技大學 通信工程學院, 陜西 西安 710071; 3.北京電子科技學院 網絡空間安全系,北京 100070)

隨著信息技術的快速普及,溯源系統在追溯產品信息、處理安全事故等方面發揮了重要的作用[1]。近年來,物聯網、區塊鏈技術的快速發展為溯源系統的迭代更新帶來了新的可能。中國政府早在2019年就提出要探索“區塊鏈+”,希望能在商品防偽等領域為人們提供便捷的服務[2]。

中國互聯網公司如阿里巴巴、騰訊等也都展開了相關研究,國內外學者都有進一步研究和應用[3]。Li等[4]在介紹區塊鏈架構模型和關鍵技術的基礎上,設計了一種產品追溯模型,但該模型無法保證源頭數據的真實可靠。Baralla等[5]在一種工廠到家庭(factory to family,F2F)的新型營銷模型基礎上,運用區塊鏈設計了一種農產品追溯系統,并利用二維碼(quick response code,QR code)驗證了產品的部分信息,但系統數據訪問率較低。張國英等[6]通過智能合約建立起溯源數據模型以記錄溯源信息,進而確保溯源信息不可篡改,但是由于區塊存儲容量有限,沒能做到批量數據的存儲。劉雅東[7]基于以太坊搭建了一個溯源信息存儲平臺,雖然提高了感知數據的安全性,但基于工作量證明(proof of work,PoW)的共識機制造成了大量的能源消耗和算力資源浪費。高琰晨[8]針對物流行業成員間的激勵契約設計了一種基于區塊鏈的物流信息追溯模型,但該模型并不能滿足實際生產的需求。

以上方案雖然利用區塊鏈技術解決了產品追溯問題,但是現有解決方案大都采用單區塊鏈實現產品溯源。單鏈方案中的大多數也都集中在解決數據的防篡改和去信任化問題上,而忽視了源頭數據的真實可靠性。此外,單一的公有鏈或者私有鏈也因為工作效率較低而難以滿足實際生產的需求。面對單鏈方案的不足,不少學者開始思考采用雙鏈模式來解決這些問題。Leng等[9]利用一條區塊鏈存儲所有公用數據,另一條區塊鏈記錄敏感數據,不僅解決了數據泄露問題,保障了數據安全性,而且提高了數據訪問效率。劉家稷等[10]在文獻[9]的基礎上利用公有鏈和私有鏈構建了一種防偽溯源系統,在保證溯源信息真實可靠的同時,做到了以高效率低成本的方式運行。以上解決方案雖然彌補了單鏈方案的不足,但仍沒有解決溯源系統數據大批量存儲的問題。而星際文件系統(interplanetary file system,IPFS)作為一種分布式文件系統,為該問題提供了一種可行的解決方案。

高文濤等[11]基于聯盟區塊鏈和IPFS技術,提出一種去中心化的音樂共享模型,實現了安全透明的音樂數據存儲和共享。馮國富等[12]提出一種區塊鏈和IPFS技術相結合的水產品交易溯源模型,在保證交易數據安全的同時,解決了傳統水產品交易溯源系統存在的數據共享難、產品追溯難等問題。曾衛民[13]提出一種IPFS和區塊鏈技術相結合的溯源方案模型,解決了傳統食品供應鏈隱私泄露、大批量數據存儲難等問題。

雖然上述解決方案將區塊鏈與IPFS技術相結合,實現了產品的可追溯以及數據的可靠存儲與共享。但以上方案大都采用權益證明(proof of stake,PoS)共識機制、代理權益證明(delegated proof of stake,DPoS)共識機制、PoW共識機制以及實用拜占庭容錯(practical Byzantine fault tolerance,PBFT)共識機制。其中,PoS共識機制和DPoS共識機制由于部分主節點掌握著區塊記賬權,過程十分煩瑣,影響了區塊鏈的進一步應用;PBFT 共識機制雖然可以在保持安全性的條件下實現(N-1)/3 的容錯性,但是PBFT共識機制的時間復雜度為O(N2),因而該機制的擴展性較差;PoW共識機制因為要找到滿足一定條件的Nonce值,所以需要進行大量的哈希運算,這造成了電力和各種算力資源的浪費。針對這些問題,容量證明(proof of capacity,PoC)共識機制應運而生。PoC將PoW中需要付出的計算資源改為付出一定數量的存儲空間,從而減少PoW共識工作過程造成的浪費。目前,國內外對PoC共識的應用還相對較少。

綜合上述分析,本文提出一種基于雙區塊鏈的產品溯源方案。利用區塊鏈和星際文件系統實現交易信息的可追溯、溯源文件的可靠存儲和共享,利用改進后的PoC共識保障溯源交易的透明度和可靠度。

本文所做主要工作如下。

(1)提出一種改進型PoC共識機制。針對傳統PoW共識耗能高的缺點,提出一種改進型PoC共識,能夠對抗其他PoC的多挖操作,功耗遠遠低于比特幣的資源開銷。

(2)基于雙區塊鏈模式的產品溯源系統設計與實現。系統實現了用戶注冊登錄、溯源信息上傳、查詢以及溯源文件提取等功能,并且針對傳統區塊鏈不適合存儲大文件的情況,使用存儲鏈和IPFS技術實現了區塊鏈的可靠查詢和溯源信息的大批量存儲。

(3)雙區塊鏈產品溯源系統的測試與分析。對各模塊進行功能測試,對PoC共識機制的優勢通過系統溯源的交易量,文件提取速度、穩定性等方面進行測試與分析,并驗證了文件存儲準確性。

1 相關技術

1.1 區塊鏈技術

區塊鏈本質上是一個分布式賬本,具備去中心化、防篡改、可追溯等特性。區塊鏈中的節點通過競爭打包生成新區塊,并按照時間的順序以鏈表的形式進行連接組成區塊鏈。其中的每個區塊都包含上一區塊的哈希值、交易信息和隨機數等信息[14]。

1.2 PoC共識算法

PoC共識算法整個過程分為兩個階段[15],這兩個階段由證明者和驗證者來完成。算法第1階段,驗證者生成一個隨機大小的文件,然后發送給證明者進行存儲,驗證者只需存儲文件的部分內容;算法第2階段,驗證者要求證明者發送一個指定位置的文件片段,證明者為保證能正確回答問題,必須保存整個文件,故而驗證者只需要保存一段數據即可。

1.3 IPFS技術

IPFS通過引入基于內容的尋址方式,采用去中心化的對等網絡進行信息交換,是一種分布式的數據存儲系統,可廣泛應用于數據共享和數據傳播領域,并確保數據的真實性[16]。

2 系統原型設計

2.1 系統溯源流程

系統溯源流程如圖1所示。其中,自身回溯鏈(my retrospective blockchain,MyRTP)作為查詢鏈便于客戶進行相關溯源信息的查詢;自身存儲鏈(my storage blockchain, MySTO)作為存儲鏈進行溯源信息文件的存儲,并做權限下載,確保數據信息的安全流通。

圖1 溯源系統流程示意圖Figure 1 Schematic diagram of traceability system

2.2 系統功能模型

系統功能模型如圖2所示。其中,用戶模塊實現了用戶注冊與登錄功能;交易模塊實現了溯源數據上鏈和區塊同步管理;挖礦模塊包含P盤掃盤和爆塊驗證,實現了溯源數據的交易信息確認,并打包到區塊鏈上產生虛擬幣;存儲模塊實現了交易信息上鏈和溯源信息IPFS存儲及下載;P2P模塊實現了區塊鏈中的節點同步和管理;查詢模塊實現了產品溯源和交易信息查詢的功能。

圖2 溯源系統功能模型Figure 2 Functional model of traceability system

2.3 改進型PoC共識機制實現

2.3.1 PoC共識機制實現

PoC共識機制的實現主要分為生成Plot文件和區塊鍛造兩個過程。

(1)生成Plot文件。Plot文件是由一系列哈希運算結果排列組合而成的數據陣列。構成該數據陣列的基本單元被稱為元胞(Nonce Cell)。Nonce Cell的生成需要使用礦工8 Byte的數字賬戶ID地址拼接一個8 Byte大小的隨機數種子(Nonce Number),構成一個大小為16 Byte初始種子(Initial Seed),之后對初始種子進行1次Shabal256()計算,便可得到第1個哈希結果#8 191,如圖3所示。

圖3 第一個哈希結果#8 191Figure 3 The first Hash result #8 191

將第1個Hash結果#8 191添加到初始種子之前可得到新的種子：#8 191+InitialSeed。隨后進行Shabal256()運算,得到第二個哈希結果#8 190;按照此種方式一直計算下去,最終可得到最后的哈希結果即FinalHash。

如果在生成新種子的過程當中,種子長度超過了4 096 Byte,此時僅保留種子長度的后4 096 Byte。之后,再將利用該種子生成的FinalHash與先前計算得到的8 192個哈希結果做異或運算。

將異或運算后得到的8 192個哈希值按照順序,每兩個合并為一個Scoop并填入到Nonce Cell中,最終將得到一個包含4 096個Scoop的256 KB的Nonce Cell,如圖4所示。通過不斷生成Nonce Cell,并對這些Nonce Cell做優化后進行排列,最后寫入Plot文件,直至寫滿該文件。

圖4 生成Nonce CellFigure 4 Generating the Nonce Cell

(2)區塊鍛造。礦工在生成好Plot文件后,即可獲取區塊的打包和記賬權,以完成溯源交易信息的確認。用戶在提交溯源信息以后,礦工將在廣播中接收到交易信息,并將該交易信息打包生成一個待出塊的區塊。礦工在進行挖礦獲取記賬權時,首先要通過錢包獲取挖礦的基本信息,包括簽名(Generation Signature)、目標(Base Target)和下一區塊高度(Height)。礦工將簽名和區塊高度進行組合作為種子,并做Shabal256()運算,得到生成哈希。然后對該哈希值做取模運算,取模數字是每個Nonce中Scoop的數量,也就是4 096。取模運算以后將得到一個4 096以內的數字,該數字就是ScoopNumber。

挖礦的過程即檢索并取出Plot文件中所有對應ScoopNumber中的Scoop數據,并將該數據(64位)和Generation Signature(64位)進行組合作為一個新的種子,然后對其進行Shabal256()運算,從而得到Target;之后將Target除以代表系統難度的參數值BaseTarget,可得到區塊倒計時(Deadline,8位),如圖5所示。

圖5 Deadline生成Figure 5 Deadline generation

Deadline表示自上個區塊出塊以后,產生新的區塊需要等待的時間。在該時間未結束前,新產生的區塊是不合法的,并不會被區塊鏈網絡所接受。之后,所有礦工將自己找到的Deadline廣播至區塊鏈網絡,進而找到最小的Deadline,此過程即為掃盤過程。當上一區塊距離當前經過的時間已經達到或者超過了自己找到的Deadline,并且沒有其他礦工提交過更小的Deadline,則該礦工將獲得當前區塊的打包權和記賬權。

2.3.2 PoC共識機制改進

在生成Plot文件時,通過不斷生成Nonce Cell,并對其優化排序,再寫入Plot,最終寫滿整個文件。由于Nonce值生成后可能存在P盤文件雷同的問題,因此本文在PoC共識機制的基礎上進行了改進。

在生成Plot文件的過程中,Nonce值生成后,通過將Nonce Cell做置換處理來避免P盤文件雷同的問題。具體為將先前的8 192個散列值與最終散列值逐一異或,并保存8 192個異或散列值,如圖6所示。

圖6 Nonce值鏡像互換Figure 6 Mirror swap of Nonce values

在Nonce值鏡像互換后,以字節為單位,字節位7和字節位0進行交換、字節位5和字節位2進行交換,以此類推按位交換操作后,得到最終的Plot文件。

3 系統關鍵部分實現

3.1 系統開發環境

系統基于Windows環境開發,后端利用C#進行開發,前端基于Java和Html語言進行編寫,系統編程軟件采用Visual Studio 2017。此外,利用H2數據庫搭建了本地數據庫。

3.2 MyRTP查詢鏈實現

3.2.1 產品信息注冊與登錄

系統中產品信息的注冊是通過電子標簽的識別來實現。讀卡器讀取串口后,自動讀取電子標簽的卡號和原始數據,識別成功后,讀卡器會經過Shabal256()加密轉換為一個32位字符長度的哈希值,該Hash值經過SM3()加密后作為溯源系統的腦密碼登錄溯源系統。腦密碼是每個產品登錄溯源系統的唯一登錄密碼,登錄系統后,可自動生成唯一的賬戶ID和數字賬戶ID(即產品ID)以及公鑰。

(1)UHF卡識別。超高頻(ultra high frequency,UHF)卡識別是射頻識別(radio frequency identification,RFID)電子標簽中的一種,具有可識別距離長、無源、防沖突性好的優點。UHF讀卡器接通電源后,通過調用btnConn_Click()事件,使用GetInstance()方法讀取讀卡器的串口號和波特率,完成與讀卡器的串口通信。

在實現串口通信后,讀卡器使用幀定義完成電子標簽協議中Inventory()操作來獲取UHF卡中的數據信息。獲取UHF卡數據的關鍵代碼如代碼1所示。

代碼1 獲取UHF卡數據的關鍵代碼private void btn_invt2_Click(object sender, EventArgs e){LoopNum_cnt=LoopNum_cnt + 1;txtSend.Text=Commands.BuildReadSingleFrame();Sp.GetInstance().Send(txtSend.Text);}

(2)數據置換。讀卡器在獲取UHF卡信息后,將對初始數據進行置換。通過調用UTF8.GetBytes()函數來避免因編碼方式所造成的字符數據傳遞失敗。利用“EPC.password + MyRTP”對內容進行轉換編碼,以便于向hashData完整傳遞數據信息。hashData接收完數據信息之后,利用sha.ComputeHash()對數據進行50輪次Shabal256()哈希運算,待運算結束后,32字節的哈希內容將通過擴展的方式被填充至字節當中,擴展方式如代碼2所示。

代碼2 數據置換擴展的關鍵代碼for (int i=0; i<50; i++){byte[ ] longHashData=hashData;for (int j=0; j

隨后將擴展后的32位字節作為初始信息進而調用全節點錢包,錢包入口為http：//127.0.0.1∶5125,并使用SM3($('#login_password').val())運算進行加密置換從而得到錢包登錄密鑰。

作為產品登錄MyRTP鏈的唯一方式,系統對產品信息進行確認后統一發放虛擬幣,并將對應產品進行綁定。

(3)賬戶ID生成。MyRTP鏈的產品ID默認是錢包登錄密鑰派生的32 位標識符,而賬戶ID根據錢包登錄密鑰采用里所(Reed-Solomon,RS)編碼方式轉換生成。之所以采用RS編碼方式,是因為此類編碼方式將使地址信息很容易被識別為屬于MyRTP。MyRTP使用4個“校驗位”來區分不同的地址信息,并且隨機地址發生沖突的機會是1/10-6(20位冗余度)。同時,最多可糾正1個地址信息中的2個錯字,最多可檢測到1個地址信息中的4個錯字。

RS編碼通過引入冗余來提高可靠性,該冗余能夠在用戶輸入MyRTP賬號時檢測并糾正錯誤,其地址格式為MYRTP-××××-××××-××××-×××××,其中,×代表數字或字母字符。為了避免出現地址混淆系統未使用字母O和I、數字1 和0。系統采用統一格式,地址始終以“MYRTP”為前綴,所有地址都使用大寫字母顯示,并且使用連字符將地址分為4、4、4、5 長度的字符組。在地址輸入期間系統不強制執行,同時識別并支持數字地址,以實現向后兼容。

(4)公私鑰獲取。登錄系統后,系統通過調用Curve25519.clamp()方法將Shabal256()加密后的32位字符輸入。然后對字符串第1位與最后1位進行邏輯運算,進而得到32位字符的賬戶私鑰。

通過調用Curve25519.keygen()方法將Shabal256()加密后的32位字符輸入。經Curve25519.clamp()方法運算獲得私鑰后,然后利用Core()方法將私鑰轉換為32字節公鑰數據。

3.2.2 溯源信息上傳

上傳溯源信息時,用戶需要登錄區塊鏈錢包,然后才能進行溯源信息的上傳。同時系統將生成的哈希值作為提取碼,用于存儲鏈上文件的下載。區塊鏈在接收到交易信息后,會將交易信息寫入交易池,等到礦工挖礦成功后將區塊數據寫入區塊鏈并進行廣播。

(1)登錄錢包賬戶。用戶通過輪詢方式獲取信息后,通過Shabal256()和SM3()加密置換,得到密鑰登錄錢包。

(2)信息上傳。當用戶使用賬戶ID登錄區塊鏈并上傳溯源信息時,區塊鏈錢包將利用Web服務器打開dgs.html網頁,將地址信息、用戶描述、文件信息、交易費用等信息錄入,然后通過API接口調用DGSListing.java進行數據的傳輸。

DGSListing.java利用自身的DGSListin()將數據以("name", "description", "tags", "quantity", "priceNQT") 格式傳遞到 APITag.CREATE_TRANSACTION中,并將該交易信息打包發送到未確認交易池。交易池確認后,將信息打包后發送至區塊鏈網絡,從而完成數據記錄的上鏈。溯源信息上傳的關鍵代碼如代碼3所示。

代碼3 溯源信息上傳的關鍵代碼private DGSListing() {super(new APITag[ ]{APITag.DGS,APITag.CREATE_TRANSACTION},"name", "description", "tags", "quan-tity", "priceNQT");}String name=Convert.emptyToNull(req.getParameter("name"));String description=Convert.nullToEmpty(req.getParameter("description"));String tags=Convert.nullToEmpty(req.getParameter("tags"));long priceNQT=ParameterParser.getPriceNQT(req);int quantity=ParameterParser.getGoodsQuantity(req);}

3.2.3 用戶信息管理

用戶進行信息傳輸時,通過Web端錢包接口進入。用戶信息管理模塊主要實現了查看賬戶ID、用戶公鑰、溯源信息查詢等功能。

(1)用戶信息管理模塊連接。系統利用Jetty實現一個動態的內容服務器,完成區塊鏈與Web頁面的端口交互。Jetty是一個輕量級的開源HTTP服務器,具備可擴展、易嵌入、高效的優點。系統通過導入Eclipse的Jetty代碼庫來實現端口的交互。

(2)數據庫調用。MyRTP主要應用的是H2數據庫。H2數據庫中主要涉及的信息包括賬戶ID、區塊ID、交易費用、時間戳等信息。

3.2.4 交易模塊實現

系統生成的溯源區塊信息記錄在區塊鏈上由礦工完成。礦工在完成初始化準備后,從錢包獲取挖塊信息,通過生成簽名并用Shabal256()算法獲取新哈希值,運算后爭奪最新區塊的記賬權,貨幣作為獎勵分發。

(1)P盤實現。首先,在硬盤中確定空余的空間,之后使用P盤軟件,按照engraver.exe,d,-n,8 192,-id,18 161 244 656 848 818 323,-sn,10 000的格式開始P盤,寫入Nonce值。其中n表示Nonce的數量,為8 192,id為礦工賬號ID,sn為Nonce的開始數值。

(2)區塊數據信息同步。在溯源信息打包發送至未確認交易池后,區塊鏈將未確認交易通過P2P網絡進行廣播,并驗證交易的金額加上手續費是否小于等于該賬戶的可用余額。若滿足該條件,系統將創建UnconfirmedTransactions()對象,并對該對象進行校驗和簽名,然后添加到“未確定交易”隊列,并廣播“未確定交易”到P2P網絡,如圖7所示。

圖7 P2P廣播節點信息Figure 7 P2P broadcast node information

(3)區塊合法性檢驗。區塊合法性校驗是在礦工計算出最小的Deadline值后,將其Nonce ID、賬戶ID參數和區塊信息發送給錢包節點。錢包通過調用Mining Plot()方法計算出Nonce值,進而廣播到全網,全網節點通過接收到的Nonce值來驗證礦工的Deadline。

3.3 MYSTO存儲鏈實現

3.3.1 IPFS環境搭建

系統IPFS環境基于go語言實現。利用私有證書,搭建了IPFS私有集群,所有全節點運行IPFS節點,數據和區塊鏈全節點保持同步。若有新添加到1個節點的數據,會同步廣播到其他私有節點上。

3.3.2 溯源信息存儲

在完成IPFS的搭建后,信息的存儲通過調用如表1所示模塊進行實現。ipfs daemon模塊初始化以后,才能進行信息的添加、下載等操作。通過ipfs add模塊將文件進行分片存儲,并調用dag層緩存到內存,進而存儲至本地。然后再利用dag調用交換層,進而廣播宣告provide信息,將其存儲至分布式散列表(distributed Hash table,DHT)中。通過ipfs get模塊提取IPFS中的文件。

提取文件通過調用dag層來實現,若本地存在該內容則將文件另存到目標位置;若本地不存在該內容,則由dag服務調用交換、路由、網絡獲取對應內容。

在對IPFS 初始化以后,可將大批量文件上傳至IPFS。同時利用區塊鏈同步功能將IPFS與MySTO相結合,使IPFS 成為區塊鏈存儲的一部分。

表1 IPFS關鍵模塊Table 1 IPFS key modules

利用IPFS共享密鑰的方式,通過區塊鏈直接調用IPFS模塊,使IPFS成為區塊鏈的一部分,不僅解決了大文件存儲問題,而且能夠使IPFS的每個節點與區塊鏈全節點都完成數據的同步更新。

3.4 雙區塊鏈聯通實現

雙鏈存儲的方式借鑒鏈式結構的優點,通過區塊鏈交易無序的特征來構造鏈式交易結構,不僅避免了傳統數據庫中心化的問題,而且有效彌補了單鏈節點存儲空間有限的缺點。

MyRTP鏈與MySTO鏈之間通過Web brige 進行交互調用,從而實現查詢鏈和存儲鏈的結合,兩鏈均采用PoC共識機制。系統功能的具體實現可分為溯源數據查詢和數據文件存儲兩大部分,分別對應系統中的MyRTP與MySTO區塊鏈。需要進行溯源信息上傳時,首先在MyRTP進行基本記錄,MyRTP錢包地址為http：//127.0.0.1∶5125。若產品存在文件、圖片、視頻等大文件需要進行存儲,則可以文件的形式上傳至MySTO,其流程如圖8所示。MySTO錢包地址為 http：//127.0.0.1∶9125,兩條鏈的掃盤路徑通過plot_dirs()設置。

從MyRTP上傳到MySTO是通過調用jQuery庫的post()方法實現的。然后利用post()方法中的 Http post請求即可從服務器加載數據。MyRTP 上傳文件到MySTO時,通過Web bridge發送post命令,構造post的報文頭。

圖8 MyRTP上傳信息至MySTOFigure 8 MyRTP uploads information to MySTO

MySTO收到交易請求后,通過調用API接口,在核實區塊合法性信息后扣除交易手續費,將其廣播至區塊鏈網絡中。

從MyRTP到MySTO,溯源數據通過post方式完成兩鏈聯通,并通過createTransaction()將信息上鏈存儲。已存儲文件通過add命令添加至IPFS系統,并生成唯一哈希值記錄在MySTO區塊鏈上。用戶可憑借此哈希值完成溯源文件的提取。

4 系統測試與分析

4.1 系統功能測試與分析

4.1.1 信息登錄功能測試

系統登錄模塊主要調用了UHF電子標簽讀取、數據解析、串口識別、數據轉換、區塊鏈錢包接入等方法。啟動射頻識別讀卡器,刷卡,使用射頻識別電子標簽,登錄查詢鏈MyRTP,如圖9所示。

圖9 賬戶詳細信息Figure 9 Account details

溯源信息打包上鏈后,礦工為競爭記賬權進行爆塊,打包區塊信息到區塊鏈并進行廣播。區塊鏈其他節點確認交易后,用戶即可在區塊鏈上查詢到自己上傳的區塊信息。

4.1.2 溯源信息查詢功能測試

系統用戶通過注冊后的ID信息作為登錄溯源系統的腦密碼,通過Web接口登錄到系統的查詢界面,可看到區塊鏈上的所有交易信息,如圖10所示。

圖10 溯源信息查詢Figure 10 Traceability information query

若用戶對指定產品進行查詢,則可通過輸入產品對應的唯一賬戶ID,即可查到該產品在生產和運輸過程中的溯源信息;對于存放在MySTO鏈的具體溯源信息,可通過哈希值從MySTO鏈提取。

4.1.3 溯源信息存儲功能測試

對于大批量的溯源信息,在登錄系統并獲得公私鑰的基礎上,可選擇本地文件進行上傳,上傳成功后,返回文件的特征哈希值作為文件的存儲憑證。當需要下載時,客戶可憑此憑證進行文件的提取,如圖11所示。

圖11 文件提取Figure 11 File extraction

4.2 系統性能測試與分析

4.2.1 溯源查詢性能測試

對系統溯源查詢性能進行測試。在區塊鏈高度為8 335情況下,根據溯源標簽進行產品溯源查詢,http響應時間為7 ms,如圖12所示。

圖12 查詢性能測試Figure 12 Query performance test

4.2.2 溯源存儲性能測試

(1)系統上傳與下載測試。系統經過上傳測試,上傳平均速度80.66 M/s;系統經過下載測試,下載平均速度90.75 M/s,具有良好的上傳和下載性能,具體測試數據如表2所示。

表2 系統上傳、下載性能測試表Table 2 System upload and download performance test table

(2)系統交易測試。隨著區塊鏈的不斷發展,部分主流區塊鏈項目因網絡阻塞問題導致無法在高并發業務領域實施。利用Hyperledger Caliper工具對MyRTP鏈和部分主流區塊鏈項目進行測試分析,表3為交易測試詳情。

表3 MyRTP與其他虛擬貨幣的交易測試Table 3 Transaction test between MyRTP and other virtual currencies

TPS指系統每秒能夠處理的事務數,是衡量區塊鏈系統性能的重要指標之一。由表3可以看出BTC每秒僅處理6.99筆交易,BCH每秒處理23.86筆交易,ETH每秒處理17.66筆交易,LTC每秒處理56.25筆交易?？梢钥闯?BCH、ETH作為繼BTC之后發展起來的區塊鏈項目,其處理交易的能力有所提升。而LTC作為最近兩年興起的新項目,在處理交易的效率上更是有了非常大的進步。本文設計實現的MyRTP鏈每秒可處理125.88筆交易,每秒所完成的交易量遠勝于其他區塊鏈主流項目,因此MyRTP鏈的工作效率也要遠高于其他區塊鏈項目。

4.2.3 惡意節點識別測試

當系統中存在未授權的惡意節點登錄時,MyRTP鏈通過賬戶余額權限設置,使其無法上傳溯源信息。為保護MySTO中存儲的溯源文件,系統以扣除余額的方式保證下載文件的統一管理。余額不足的用戶,即使拿到提取哈希值也無法進行文件的下載,如圖13所示。

圖13 MySTO無權限下載測試Figure 13 MySTO download tests without permission

4.3 系統方案對比分析

本節從共識機制、查詢性能、存儲容量、去中心化以及成本5個維度將本方案與其他溯源方案進行對比分析,如表4所示。

表4 溯源方案對比Table 4 Comparison of traceability schemes

從表4可以看出,文獻[5]中的PoET共識依靠專用硬件來保障安全性;文獻[9]和文獻[17]并沒有做到完全的去中心化,在溯源應用中無法確保數據可信;文獻[10]依賴PoW共識在生成區塊信息的同時也造成了大量的無用計算。本方案通過雙鏈模式在實現去中心化溯源的基礎上,利用IPFS提升系統可靠存儲和分享能力,同時改進PoC共識算法將PoW高能源消耗替代為低能耗的硬盤查找。不僅保證底層的安全性,而且在減少能源消耗的同時也能滿足區塊鏈溯源系統的應用需求。

5 結論

利用雙區塊鏈和IPFS技術解決了傳統溯源方案和現有單區塊鏈溯源方案所存在的數據造假、數據泄露、大批量數據存儲等問題。利用改進后的PoC共識算法解決了現有單區塊鏈和雙區塊鏈溯源方案工作效率不高的問題。經測試表明,系統在較為理想的時延范圍內實現了溯源信息的上傳、存儲和下載等功能,能夠根據區塊鏈記錄進行溯源信息過程查詢,可有效防止數據篡改和惡意攻擊,保證溯源信息結果完整可信。